2018-03-13 9:37 GMT+01:00 Robert Bradshaw <rober...@google.com>: > I think there is never any prohibition on doing a minor or bugfix release > to an old release, if we deem it worth the effort. EOLs, etc. are more > about a promise/obligation to do a bugfix release if bugs (of a certain > type or severity?) are discovered. Given how hard it's been just to get > normal releases out, and that we've never done a bugfix to anything but the > latest release, I don't know that this is something we want (or need) to > take on right now. Given our relatively firm stance on backwards > compatibility and semantic versioning, there hasn't (that I'm aware of) > been a big demand for this either yet. >
Advertising
"never" is true for now but will not in some years, would you do a bugfix release on an incubator release? not sure. Let say I am asking it now ;) Also a lot of experimental should fall into this maintenance trap or moved ourside main modules (as a beam-sdk-core-java-exp) since otherwise it is used, unreported by IDE etc and it breaks regularly. Migrations are not always straight forward or a plain "sed". > > On the other hand, when 3.0.0 appears, we should decide what the lifetime > of the 2.x series is going to be, whether any bug fixes will be backported, > and if any development is going to continue on that line. > Don't get me wrong, I'm fine with "2.x" will not get any policy but 3 will get it, but it is super important for the community and users to have visibility on that. It is the way beam will be perceived as mature or not. With current cadence and lack of policy it still looks in dev whereas, as you mentionned, a part is quite stable. Concretely I'm fine if you say me what I proposed is wrong - it is likely - but what is your alternative to try to make beam 1. better percieved, 2. usable by companies (integrable in a software plan)? > > > > On Tue, Mar 13, 2018 at 1:23 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> 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.) >>>> >>> >>> >>
