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, à 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.) >>> >> >>
