+1

Le 13 mars 2018 à 05:54, à 05:54, Romain Manni-Bucau <rmannibu...@gmail.com> a 
écrit:
>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