On 24/01/17 19:57, Andy Seaborne wrote:


On 24/01/17 12:57, Osma Suominen wrote:
23.01.2017, 19:31, Andy Seaborne kirjoitti:

To expand on that: That would mean users could get source code to build
themselves, it would not be an "Apache release" and not in maven
central.  For "products", the legal side of a release probably matters.

Source code yes, but I think it would make sense to set up some kind of
autobuilder for the stable branch, similar to how snapshots are built
nightly. It shouldn't be much effort to set this up, but it would be a
valuable service for users.

It's not an Apache release.

Snapshots are specifically allowed for developers which we include
anyone picking and testing.

They are not releases.

Products that want LTS stability will, I believe, want:
* The ASF release legal framework
* Assurance that the LTS will be around for the life of the product
* Ideally, support contracts (3rd party)

It is likely because they don't have the technical capabilities or
resources in-house to investigate and report, let alone fix.

The trouble really comes when a "bug fix" is a feature change. If the
bug is not some low thing like an NPE, one products view of a "fix" is
another products regression.

(Believe me! It's happing to me right now - a SPARQL fix to comply with
the standard has causes interesting changes.)

---------------------------

There are three options here:

* Current
  Advantage: bug fixes, most timely.
  Disadvantage: picks up everything

* A "last release+fixes" branch
  Not a release ... unless voted on
  Not long term stability (product life : years)
  Some extra work

* LTS
  Long term commitment.
  More work.

And a point about LTS - more bug reports are nice, but contributions of
fixes is much better.

I'm not convinced that item 2 would be much used - they last only 4 or 6
months as I understand the concept.

Events like Jena2->Jena3 are extremely rare.  Otherwise, we add
features, not remove them, backwards compatibility is as good as a
stable branch (I would hope!).  The low-cost way of careful adding to
master seems to me best unless we have additional contributions of fixes
(not just reports) or other resourcing.

+1

Excellent analysis and agreed that item 2 isn't likely be of much value. I can see why people might want an LTS but it's just not practical for us [says one who contributes very little these days]. Stick to current.

Dave

Reply via email to