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.
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.
On Tue, Mar 13, 2018 at 1:23 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> 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
> 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.
> 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
> 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
>>> > 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,
>>> 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
>>> > 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
>>> bits are behavioral differences. In addition, all our public APIs should
>>> covered by tests, and any changes to existing tests should be vetted in
>>> reviews and backwards incompatibility called out there.)