I would start a formal vote to have feedback from everyone and propose where to add such detail (I would suggest directly on the download/version page), then we can create a PR on the website.
Regards JB Le 13 mars 2018 à 05:44, à 05:44, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit: >Works for me. > >What's the procedure to add it on the website (and where can we add >it)? > > >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-13 13:39 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > >> 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, Romain Manni-Bucau <rmannibu...@gmail.com> >a >> écrit: >>> >>> >>> >>> 2018-03-13 12:50 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >>> >>>> 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 < >rmannibu...@gmail.com> 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 ><rmannibu...@gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2018-03-02 18:12 GMT+01:00 Robert Bradshaw <rober...@google.com>: >>>>>> >>>>>>> On Fri, Mar 2, 2018 at 8:45 AM Romain Manni-Bucau < >>>>>>> rmannibu...@gmail.com> >>>>>>> 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-st >>>>>>> arted/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.) >>>>>>> >>>>>> >>>>>> >>>>> >>>
