I can answer that one... The 'plan' was always 2 new LTS branches a year - effectively summer and winter. Remember at the time, some members of the community were going for a release every month. So the idea was - whatever the branch was the current branch at the time that an LTS was due, that branch would get some 'extra treatment' and be supported for a few years rather than a few months.
Very importantly, the post x.x.0 LTS releases were to have no new features - just bugfixes. So larger organisations with stricter change control, their own documentation and their own integrations, could stay on a 'supported' branch but still get bug fixes in releases, without having to worry about, test or document new features constantly. (I'll hand-wave over the fact that one person's feature is another person's improvement, is another person's bugfix) Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1 with all critical/blocker/major bugfixes in it (probably as soon as enough people have recovered from a 4.14 release cycle) but it can't have any new features in it. So looking forward, if someone wants a 4.15 release in (say) April, then the 'summer' LTS branch (July/August time) will be 4.16, if not, then the summer LTS release would be 4.15 I hope that helps 😊 Kind regards Paul. paul.an...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -----Original Message----- From: Gabriel Beims Bräscher <gabrasc...@gmail.com> Sent: 19 December 2019 16:59 To: dev <dev@cloudstack.apache.org> Subject: Re: [PROPOSE] RM for 4.14 Hello Andrija, That is always good news to have contributors stepping up and getting new releases done. We definitely need a release (either a major or a 4.13.1.0) to keep the project traction. However, I would like to understand why 4.14.0.0 is being considered an LTS release. As far as I know, the next major release was supposed to be a regular (non-LTS) release in the midle of the current LTS and next one LTS. Our current LTS 4.13.0.0 is young and with still has some room for bugfixes. For reference, here follows the Release Calendar, more details at [1]. 4.9.2.0, LTS, released at 15 December 2016, EOL 1 July 2018 4.9.3.0, LTS, released at 11 September 2017, EOL 1 July 2018 4.11.0.0, LTS, released at 12 February 2018, EOL July 2019 4.12.0.0, Regular, released at 4 April 2019, N/A 4.13.0.0, LTS, released at 24 September 2019, Current LTS 4.14.0.0, LTS/Regular, planned to 21.Feb 2019+ [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS Regards, Gabriel. Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel <s.vo...@ewerk.com> escreveu: > Hi Andrija, > > How can I help and engage in this process? > > Cheers > > Sven > > > > __ > > Sven Vogel > Teamlead Platform > > EWERK DIGITAL GmbH > Brühl 24, D-04109 Leipzig > P +49 341 42649 - 99 > F +49 341 42649 - 98 > s.vo...@ewerk.com > www.ewerk.com > > Geschäftsführer: > Dr. Erik Wende, Hendrik Schubert, Frank Richter > Registergericht: Leipzig HRB 9065 > > Zertifiziert nach: > ISO/IEC 27001:2013 > DIN EN ISO 9001:2015 > DIN ISO/IEC 20000-1:2011 > > EWERK-Blog | LinkedIn | Xing | Twitter | Facebook > > Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. > > Disclaimer Privacy: > Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) > ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht > der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, > Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte > informieren Sie in diesem Fall unverzüglich den Absender und löschen > Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. > Vielen Dank. > > The contents of this e-mail (including any attachments) are > confidential and may be legally privileged. If you are not the > intended recipient of this e-mail, any disclosure, copying, > distribution or use of its contents is strictly prohibited, and you > should please notify the sender immediately and then delete it (including any > attachments) from your system. Thank you. > Am 19.12.2019 um 17:05 schrieb Andrija Panic <andrija.pa...@gmail.com>: > > > > Hi All, > > > > I’d like to put myself forward as release manager for 4.14. The > > 4.14 releases will be the next major version LTS release and will be > > supported for 20 months per the LTS manifesto [2]. > > > > I'll have support from Rohit/Daan/Paul during the process and anyone > > else interested is most welcome to join the effort. > > > > The proposed timeline (possibly a bit too ambitious) is as follows: > > > > ###################################### > > 24.Jan 2019 --> Code freeze > > 31.Jan-07.Feb 2019 --> Cut first RC > > 21.Feb 2019+ --> Release > > ###################################### > > > > As usual, kindly note the following "behaviour" to be in place > > (pretty much copy/paste from the related 4.11 email from Rohit): > > > > ###################################### > > 1. After the freeze date (expected 24th Jan) until GA release, > > features will not be allowed and fixes will be only as long as there > > are blocker issues outstanding. Fixes for other issues will be > > individually judged on their merit and risk. > > 2. RM will triage/report critical and blocker bugs for 4.14 and > > encourage people to get them fixed. > > 3. RM will create RCs and start voting once blocker bugs are cleared > > and baseline smoke test results are on par with previous 4.13 smoke > > test > results > > test results. > > 4. RM will allocate at least a week for branch stabilization and testing. > > At the earliest, on 31st January, RM will put 4.14.0.0-rc1 for > > voting > from > > the 4.14 branch, and master will be open to accepting new features. > > 5. RM will repeat 2-4 as required. Voting/testing of -rc2, -rc3 and > > so > on, > > will be created as required > > 6. Once vote passes - RM will continue with the release procedures [1]. > > > > I’d like the community (including myself and colleagues) to: > > - Up to 24th January, community members try to review, test and > > merge as many fixes as possible, being super-diligent to not > > de-stabilize the master branch. > > - Engage with gatekeepers to get your PRs reviewed, tested and > > merged (currently myself, Rohit, Daan and Paul, others are welcome > > to engage as well). Do not merge the PRs > > - A pull request may be reverted where the author(s) are not > > responding and authors may be asked to re-submit their changes after > > taking suitable remedies. > > > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu > re > > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS > > ###################################### > > -- > > > > > > Andrija Panić >
