Re: Releases and user support

2018-03-24 Thread Romain Manni-Bucau
Is it something we can add now the 2.4 is out? Le 13 mars 2018 16:02, "Jean-Baptiste Onofré" a écrit : > You can also take a look on karaf download page about the schedule and > active table. > > Regards > JB > Le 13 mars 2018, à 07:52, Romain Manni-Bucau

Re: Releases and user support

2018-03-13 Thread Jean-Baptiste Onofré
You can also take a look on karaf download page about the schedule and active table. Regards JB Le 13 mars 2018 à 07:52, à 07:52, Romain Manni-Bucau a écrit: >Just to illustrate what I was looking for @beam: this kind of page

Re: Releases and user support

2018-03-13 Thread Romain Manni-Bucau
Just to illustrate what I was looking for @beam: this kind of page https://tomcat.apache.org/tomcat-80-eol.html but maybe not that fine grained. Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: Releases and user support

2018-03-13 Thread Reuven Lax
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

Re: Releases and user support

2018-03-13 Thread Jean-Baptiste Onofré
+1 Le 13 mars 2018 à 05:54, à 05:54, Romain Manni-Bucau 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

Re: Releases and user support

2018-03-13 Thread Romain Manni-Bucau
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 | Blog | Old Blog |

Re: Releases and user support

2018-03-13 Thread Jean-Baptiste Onofré
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, à 05:44, Romain Manni-Bucau a écrit:

Re: Releases and user support

2018-03-13 Thread Romain Manni-Bucau
Works for me. What's the procedure to add it on the website (and where can we add it)? Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

Re: Releases and user support

2018-03-13 Thread Jean-Baptiste Onofré
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

Re: Releases and user support

2018-03-13 Thread Romain Manni-Bucau
2018-03-13 12:50 GMT+01:00 Jean-Baptiste Onofré : > 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. >

Re: Releases and user support

2018-03-13 Thread Jean-Baptiste Onofré
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

Re: Releases and user support

2018-03-13 Thread Romain Manni-Bucau
2018-03-13 9:37 GMT+01:00 Robert Bradshaw : > I think there is never any prohibition on doing a minor or bugfix release > to an old release, if we deem it worth the effort. EOLs, etc. are more > about a promise/obligation to do a bugfix release if bugs (of a certain > type or

Re: Releases and user support

2018-03-13 Thread Robert Bradshaw
I think there is never any prohibition on doing a minor or bugfix release to an old release, if we deem it worth the effort. EOLs, etc. are more about a promise/obligation to do a bugfix release if bugs (of a certain type or severity?) are discovered. Given how hard it's been just to get normal

Re: Releases and user support

2018-03-13 Thread Romain Manni-Bucau
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

Re: Releases and user support

2018-03-06 Thread Romain Manni-Bucau
2018-03-02 18:12 GMT+01:00 Robert Bradshaw : > On Fri, Mar 2, 2018 at 8:45 AM Romain Manni-Bucau > 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

Re: Releases and user support

2018-03-02 Thread Robert Bradshaw
On Fri, Mar 2, 2018 at 8:45 AM Romain Manni-Bucau 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