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é <[email protected]>: > 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 <[email protected]> a > écrit: >> >> >> >> 2018-03-13 12:50 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >> >>> 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 < [email protected]> 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 <[email protected]>: >>>> >>>>> >>>>> >>>>> 2018-03-02 18:12 GMT+01:00 Robert Bradshaw <[email protected]>: >>>>> >>>>>> On Fri, Mar 2, 2018 at 8:45 AM Romain Manni-Bucau < >>>>>> [email protected]> >>>>>> 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.) >>>>>> >>>>> >>>>> >>>> >>
