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