sounds good, let's wait this day (so tomorrow with the timezone issue) to
see if there is any other proposals and if not start a vote tmr.


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-13 13:46 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:

> I would start a formal vote to have feedback from everyone and propose
> where to add such detail (I would suggest directly on the download/version
> page), then we can create a PR on the website.
>
> Regards
> JB
> Le 13 mars 2018, à 05:44, Romain Manni-Bucau <rmannibu...@gmail.com> a
> écrit:
>>
>> Works for me.
>>
>> What's the procedure to add it on the website (and where can we add it)?
>>
>>
>> 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-13 13:39 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>>
>>> 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, 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-st
>>>>>>>> arted/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