I agree with this. Support guarantee makes more sense for products.

Specifically, there are several organizations that have products based on
Beam (Talend, Google,Data Artisans, Spotify, etc.). These companies may
provide support guarantees to their customers, which essentially means that
they are promising to propose Beam point releases to fix bugs in supported
SDKs (subject to vote of course, but there hasn't been opposition to such
point releases in the past). Support window makes perfect sense for these
organizations, and each one might have a different support window. However
this is a policy of these organizations, not of the Beam project.


On Tue, Mar 13, 2018 at 4:51 AM Jean-Baptiste Onofré <j...@nanthrax.net>

> Hi
> I don't think this statement is appropriate as it sounds more like product
> than project.
> Let me explain.
> At Apache, anyone can propose and do a release based on any version,
> including very old ones.
> Support sounds like the assessment that we are committed to provide fixes.
> That's more a product or company engagement if we talk about "support".
> From a Apache standpoint, that's actually a best effort valid
>   with any branch or version.
> I would rather talk about active branches.
> Even if we do 3.0.0 now, it's completely acceptable to do 2.0.1 in 5 years
> if needed. On the other hand, 3.0.x branch  can become inactive in 2 months.
> That's why I'm not very comfortable to take such statement in the project.
> My €0.01
> Regards
> JB
> Le 13 mars 2018, à 01:23, Romain Manni-Bucau <rmannibu...@gmail.com> a
> écrit:
>> 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.)

Reply via email to