The reason is just having a time boxed approach. Otherwise it may ends without having a LTS at all
Il mar 3 mar 2020, 20:18 Federico Valeri <fedeval...@gmail.com> ha scritto: > Hi, I'm +1 with LTS support, but what are the benefits of such strict > schedule? > > I think that would be better to release as LTS whenever it makes sense. > > my2cents > > On Tue, Mar 3, 2020, 5:59 AM Ajmera, Hemang C <hemang.ajm...@cgi.com> > wrote: > > > Hi > > From the user perspective LTS is a welcome move. I liked the approach > > which is proposed here. You can also refer to Ubuntu release cycle[1] > where > > every 6 month there is new release and every 2 year there is LTS release. > > LTS are supported for 5 years. So if we sum up, Every fourth release is > > LTS, and life of LTS is for 2.5 LTS cycle. > > > > For camel world the release would be more frequent compared to Ubuntu > > > > So every six month 1 LTS and two releases in between should be fine. If > we > > want more frequent release we can have 3 non LTS release in between, i.e. > > release after every 6 weeks. > > > > > > > > > > [1] https://wiki.ubuntu.com/Releases > > > > Thanks and Regards, > > Hemang Ajmera > > > > -----Original Message----- > > From: Claus Ibsen <claus.ib...@gmail.com> > > Sent: 02 March 2020 17:00 > > To: dev <dev@camel.apache.org> > > Subject: Re: Tentative release schedule for Camel 3.x releases in 2020 > > > > Ups the last two should be flipped, eg > > > > Camel 3.5.0 in Oct 2020 (no LTS) > > Camel 3.6.0 in Dec 2020 (LTS) > > > > On Mon, Mar 2, 2020 at 12:26 PM Claus Ibsen <claus.ib...@gmail.com> > wrote: > > > > > > Hi > > > > > > Lets put a tentative release schedule for Camel 3.x for this year, > > > where we make it more obvious which releases are LTS and which are > > > not. > > > > > > For example having 2 yearly LTS releases and then non TLS in between > > > allows us to innovate and move faster, but also offer production safe > > > stable branches where end users can stay on for a longer time and get > > > CVE and important/critical bugfixes only. Note that we should shy away > > > from doing other fixes on these LTS branches as they are meant for > > > "rock sold and only really important bug fixes". Not small > > > improvements, and it would be nice to have if X can also do this etc. > > > Lets put this kind into the non LTS releases first (when possible). > > > > > > A plan could be something like > > > > > > Camel 3.1.0 in Feb 2020 (no LTS) > > > Camel 3.2.0 in April 2020 (no LTS) > > > Camel 3.3.0 in June 2020 (LTS) > > > Camel 3.4.0 in Aug 2020 (no LTS) > > > Camel 3.5.0 in Oct 2020 (LTS) > > > Camel 3.6.0 in Dec 2020 (no LTS) > > > > > > And then we do Camel 3.3.x and 3.6.x patch releases from time to time, > > > and for about 12 months, eg 2 LTS's back, eg 3.3.x is EOL when Camel > > > 3.9.0 LTS is released (about 1 year later). > > > > > > > > > Any thoughts? > > > > > > -- > > > Claus Ibsen > > > ----------------- > > > http://davsclaus.com @davsclaus > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > >
