2018-03-13 12:50 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> 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.
Works as well since it leads to the same outcome for companies: be able to
know when the code will maybe no more be maintained. (just let say it is a
"phrasing issue" here)
> 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.
This is what I try to fill as gap. "best effort" or "can do" doesnt let any
company plan anyting. Whereas "in 2 years it will be best efforts" let you
Most of big asf projects have such a statement and at least some visibility
on their EOL which is an investment guarantee for a company. This point is
key for a portable API (it is less for a particular vendor).
> That's why I'm not very comfortable to take such statement in the project.
Don't get me wrong, i'm not super comfortable today since I feel like the
API can change a lot for 3.x and having 2.x and 3.x quite different to
maintain can hurt a bit,
but not having such a statement is an issue easy to hit when you try to
"sell" beam to users (don't forget big data is not used by "small" projects
but mainly by companies only for obvious reasons ;)).
If we think in terms of active branches, what does it mean?
2 max active branches at a time?
> My €0.01
> Le 13 mars 2018, à 01:23, Romain Manni-Bucau <rmannibu...@gmail.com> a
>> 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 <
>>>> > 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
>>>> plugin, not sure about gradle but it is clearly not a technical
>>>> 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 be
>>>> covered by tests, and any changes to existing tests should be vetted in
>>>> reviews and backwards incompatibility called out there.)