You can also take a look on karaf download page about the schedule and active table.
Regards JB Le 13 mars 2018 à 07:52, à 07:52, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit: >Just to illustrate what I was looking for @beam: this kind of page >https://tomcat.apache.org/tomcat-80-eol.html but maybe not that fine >grained. > > >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 15:47 GMT+01:00 Reuven Lax <re...@google.com>: > >> I agree with this. Support guarantee makes more sense for products. >> >> Specifically, there are several organizations that have products >based on >> Beam (Talend, Google,Data Artisans, Spotify, etc.). These companies >may >> provide support guarantees to their customers, which essentially >means that >> they are promising to propose Beam point releases to fix bugs in >supported >> SDKs (subject to vote of course, but there hasn't been opposition to >such >> point releases in the past). Support window makes perfect sense for >these >> organizations, and each one might have a different support window. >However >> this is a policy of these organizations, not of the Beam project. >> >> Reuven >> >> >> On Tue, Mar 13, 2018 at 4:51 AM Jean-Baptiste Onofré ><j...@nanthrax.net> >> wrote: >> >>> 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. >>> >>> I would rather talk about active branches. >>> >>> 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. >>> >>> That's why I'm not very comfortable to take such statement in the >project. >>> >>> 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-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.) >>>>>> >>>>> >>>>> >>>>
