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.


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

Reply via email to