That's the statement I'm doing in Karaf: I have two active branches, with backward compatibility guarantee on both. If we introduce a new branch, then the oldest one is flagged as "not active" (I prefer "not active" wording than "EOL" as a release can happen on a non active branch).
In that sense of "support" and wording, I agree. Regards JB Le 13 mars 2018 à 05:23, à 05:23, Romain Manni-Bucau <[email protected]> a écrit: >2018-03-13 12:50 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > >> Hi >> >> I don't think this statement is appropriate as it sounds more like >product >> than project. >> >> Let me explain. >> >> At Apache, anyone can propose and do a release based on any version, >> including very old ones. >> Support sounds like the assessment that we are committed to provide >fixes. >> That's more a product or company engagement if we talk about >"support". >> From a Apache standpoint, that's actually a best effort valid >> with any branch or version. >> > >Agree > > >> >> I would rather talk about active branches. >> > >Works as well since it leads to the same outcome for companies: be able >to >know when the code will maybe no more be maintained. (just let say it >is a >"phrasing issue" here) > > >> >> Even if we do 3.0.0 now, it's completely acceptable to do 2.0.1 in 5 >years >> if needed. On the other hand, 3.0.x branch can become inactive in 2 >months. >> > >This is what I try to fill as gap. "best effort" or "can do" doesnt let >any >company plan anyting. Whereas "in 2 years it will be best efforts" let >you >plan ahead. > >Most of big asf projects have such a statement and at least some >visibility >on their EOL which is an investment guarantee for a company. This point >is >key for a portable API (it is less for a particular vendor). > > >> >> That's why I'm not very comfortable to take such statement in the >project. >> > >Don't get me wrong, i'm not super comfortable today since I feel like >the >API can change a lot for 3.x and having 2.x and 3.x quite different to >maintain can hurt a bit, >but not having such a statement is an issue easy to hit when you try to >"sell" beam to users (don't forget big data is not used by "small" >projects >but mainly by companies only for obvious reasons ;)). > >If we think in terms of active branches, what does it mean? > >2 max active branches at a time? > > >> >> My €0.01 >> >> Regards >> JB >> Le 13 mars 2018, à 01:23, Romain Manni-Bucau <[email protected]> >a >> écrit: >>> >>> Up? >>> >>> What about this proposal: >>> >>> 1. majors (X.y.z) are supported for 3 years >>> 2. minors (x.Y.z) are supported for 6 months (1 year? does it sound >>> doable?) >>> >>> Just to ensure it is clear: implication is if we have 3.0.0 today >then we >>> can have to do a 3.x.y ini 3 years even if we are at beam 10. >>> This is the (core dev) drawback but the advantage for the >communities >>> and companies using beam is that they know they can rely on it and >plan >>> migrations as needed to never be on a no more maintained version. >>> >>> wdyt? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> ><https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> 2018-03-06 14:10 GMT+01:00 Romain Manni-Bucau ><[email protected]>: >>> >>>> >>>> >>>> 2018-03-02 18:12 GMT+01:00 Robert Bradshaw <[email protected]>: >>>> >>>>> On Fri, Mar 2, 2018 at 8:45 AM Romain Manni-Bucau < >>>>> [email protected]> >>>>> wrote: >>>>> >>>>> > Hi guys, >>>>> >>>>> > I didn't find a page about beam release support. With the fast >minor >>>>> release rrythm which is targetted by beam (see other threads on >that), I >>>>> wonder what - as an end user - you should expect as breakage >between >>>>> versions (minor can add API but shouldn't break them typically) >and how >>>>> long a version can get fixes (can I get a fix on the 2.0.0 - 2.0.1 >- now >>>>> the 2.3.0 is out?). >>>>> >>>>> We promise semantic versioning, in particular API stability for >minor >>>>> releases: >https://beam.apache.org/get-started/downloads/#api-stability >>>>> . >>>>> >>>>> > A page with some engagements like "we support majors for 3 >years, >>>>> minors >>>>> for 6 months" would be very beneficial for end users IMO. >>>>> >>>>> Good point, though it's unclear what "support" means in the >absence of >>>>> SLOs, etc. >>>>> >>>> >>>> Agree, for OS projects like Beam I think we can limit to "you can >expect >>>> new releases on demand or need". >>>> >>>> I see it as Tomcat for instance, when EOL you can not expect any >>>> release, even for security fixes, anymore. Whereas while >"supported" you >>>> are sure bugs and vulnerabilities can get a release in a >"reasonable" >>>> time (this being up to the project on potentially on a case by case >kind of >>>> thing). >>>> >>>> >>>>> >>>>> > Technically I also think beam should use clirr (I know there is >a >>>>> maven >>>>> plugin, not sure about gradle but it is clearly not a technical >>>>> blocker). >>>>> It would allow to enforce the policy at build time and avoid >surprises. >>>>> >>>>> +1 to any and all automation of policies like this. (Of course >the >>>>> tricky >>>>> bits are behavioral differences. In addition, all our public APIs >>>>> should be >>>>> covered by tests, and any changes to existing tests should be >vetted in >>>>> reviews and backwards incompatibility called out there.) >>>>> >>>> >>>> >>>
