sounds good, let's wait this day (so tomorrow with the timezone issue) to see if there is any other proposals and if not start a vote tmr.
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:46 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > 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, 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.) >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>
