That's the statement I'm doing in Karaf: I have two active branches, with 
backward compatibility guarantee on both. If we introduce a new branch, then 
the oldest one is flagged as "not active" (I prefer "not active" wording than 
"EOL" as a release can happen on a non active branch).

In that sense of "support" and wording, I agree.

Regards
JB

Le 13 mars 2018 à 05:23, à 05:23, Romain Manni-Bucau <rmannibu...@gmail.com> a 
écrit:
>2018-03-13 12:50 GMT+01:00 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.
>>
>
>Agree
>
>
>>
>> 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
>plan ahead.
>
>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
>>
>> 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