+1
Le 13 mars 2018 à 05:54, à 05:54, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit: >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.) >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>
