I was thinking about how IBM limits access to various products internally. Basically Apache products have to be releases. All major releases have to > be approved. Minor revision number changes are easily accepted. Anything > else is a lot of paper (electron?) work. New releases mean regression > testing and that can be a painful process. So for me (at work) 3.2.x is > much easier to deal with the 3.2.x -> 3.3.0. >
So I was looking for something like 3.2.0 being denoted as LTE would mean that any bug fixes would be 3.2.x So if 3.3.0 is released the bug fixes still get applied to 3.2 for some period of time. So basically the standard LTE. However, I can see that this poses problems with such a small development team and without a major commercial backer. Having seen the discussion, I think we might be well served to just continue on as we have until someone declares they want to manage an LTE release scheme. Thank you all for the discussion and the many points raised. Claude On Tue, Jan 24, 2017 at 8:15 PM, [email protected] <[email protected]> wrote: > I think Claude introduced the idea of LTS releases, so I'm curious about > whether he thinks that the audience for stability includes people who would > use a "stable" series of the kind Osma describes, even without the Apache > imprimatur. > > ajs6f > > > On Jan 24, 2017, at 2:57 PM, Andy Seaborne <[email protected]> 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. > > > > Andy > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
