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