All, It seems that there is general agreement on the following:
1. There are users that need periodic releases that only focus on stability to minimize change and deployment risk (i.e. LTS releases) 2. There are users that need frequent releases that deliver new capabilities (i.e. monthly releases) 3. These two release types are not mutually exclusive and can be developed in a complementary manner 4. Assuming community has the resources available, we would like to deliver both monthly and LTS releases For a sometime, ShapeBlue have been considering a proposal to supplement the monthly release cycle with an LTS release cycle. We believe that offering both monthly and LTS releases will make CloudStack more attractive to new users, as well as, addressing the requirements of all current CloudStack users. I expect to publish an LTS proposal within the next day or so that includes most, if not all, of the points discussed on this thread. Hopefully, we will quickly gain consensus on an LTS release cycle, and begin doing the work necessary to deliver high quality LTS releases. Thanks, -John > [ShapeBlue]<http://www.shapeblue.com> John Burwell ShapeBlue d: +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411> e: john.burw...@shapeblue.com | t: <mailto:john.burw...@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK [cid:image5c2903.png@05139e21.40b48007] Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. On Jan 12, 2016, at 2:43 PM, Nux! <n...@li.nux.ro> wrote: > > Remi, > > Yes, that, that's great then, thanks. > > Lucian > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > ----- Original Message ----- >> From: "Remi Bergsma" <rberg...@schubergphilis.com> >> To: dev@cloudstack.apache.org >> Sent: Tuesday, 12 January, 2016 19:04:55 >> Subject: Re: LTS release or not > >> Hi Lucian, >> >> Are you referring to the forward merging? >> That has been scripted: >> https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge >> >> There may be conflicts at some point, but that also happens with >> cherry-picking. >> >> If you mean something else I probably missed your point, sorry. >> >> Regards, >> Remi >> >> >> >> >> On 12/01/16 17:17, "Nux!" <n...@li.nux.ro> wrote: >> >>> Guys, I am not a coder to appreciate how sustainable this would be. >>> >>> Who around here with actual java skills thinks this is achievable in a >>> reasonable way? Cause if it's not we're just wasting time. >>> >>> Lucian >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro >>> >>> ----- Original Message ----- >>>> From: "Remi Bergsma" <rberg...@schubergphilis.com> >>>> To: dev@cloudstack.apache.org >>>> Sent: Tuesday, 12 January, 2016 15:36:52 >>>> Subject: Re: LTS release or not >>> >>>> Hi, >>>> >>>> The method Daan describes can be done from 4.6 and on. It’s about merging >>>> a PR >>>> with a fix, and forward merging it. Not about actually releasing >>>> immediately. >>>> >>>> If the bug has always been there, one would merge to 4.6, merge forward to >>>> newer >>>> releases (and finally master) and then back port (aka cherry-pick) to 4.5. >>>> >>>> Regards, >>>> Remi >>>> >>>> >>>> >>>> On 12/01/16 15:55, "Ron Wheeler" <rwhee...@artifact-software.com> wrote: >>>> >>>>> Depending on how far back the problem originated, this may not be >>>>> practical. >>>>> The code might have been massaged many times or code may have been >>>>> written that depends on the buggy behaviour. >>>>> >>>>> If the bug "was always there" but no one had figured out the exploit, it >>>>> might not be possible to identify any particular commit at all. >>>>> >>>>> Would your solution trigger a whole bunch of new releases - 4.4.x, >>>>> 4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch >>>>> and noted while we wait for enough to accumulate to trigger a new >>>>> release? Who would want to work on 4.4.x release? >>>>> >>>>> The amount of testing required to support all that backporting would >>>>> certainly deter people from fixing old bugs! >>>>> >>>>> No code is bug free so I am not sure how bad it is to say that a bug >>>>> will only be fixed in the LTS and current release. >>>>> >>>>> System administrators can then decide if the bug is worth an update to >>>>> the fixed version or should be fixed on the release that they currently >>>>> run, causing a local fork that they will deal with during their next >>>>> upgrade cycle. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> On 12/01/2016 2:18 AM, Daan Hoogland wrote: >>>>>> ok, one last €0,01: any bug should be fixed not on the branch but on the >>>>>> commit it was introduced in and thenn be merged forward. It can then be >>>>>> merged into any branch that contains the offending commit and there is no >>>>>> longer any difference between LTS or anything else. Am I speaking >>>>>> Kardeshian? I am really surprised no one in this list sees source code >>>>>> and >>>>>> release management this way. >>>>>> >>>>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler >>>>>> <rwhee...@artifact-software.com >>>>>>> wrote: >>>>>>> There may have to be some rules about patches such as >>>>>>> "You may not apply any bug fix to a minor release that will break the >>>>>>> upgrade path." >>>>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest >>>>>>> 4.7.x >>>>>>> If a user absolutely needs a fix that breaks this, then it is their >>>>>>> problem to upgrade to 4.7.x rather than building a long-term problem >>>>>>> into a >>>>>>> stable branch. >>>>>>> At some point no one will be happy with the latest 4.6.x and everyone >>>>>>> will >>>>>>> upgraded. >>>>>>> >>>>>>> Any user that applies the offending patch to 4.6.2 should know that they >>>>>>> have created their own misery and will have to work out the upgrade at >>>>>>> some >>>>>>> point or continue their private fork forever. >>>>>>> >>>>>>> There is nothing wrong to saying that "Bug xx is only fixed in version >>>>>>> 4.8.0 and later". >>>>>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is not fixed. >>>>>>> No piece of software is bug-free so we are really discussing what >>>>>>> happens >>>>>>> once a bug is found and a fix is available. >>>>>>> 4.6.5 will run exactly like it did before the bug was found. >>>>>>> >>>>>>> Bugs that will cause update issues will trigger a new major release. >>>>>>> If the current supported releases are 4.6.2 and 4.7.1 then the bug will >>>>>>> cause a 4.8.0 to come into existence with an upgrade path that goes from >>>>>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade) to 4.8.0 >>>>>>> >>>>>>> >>>>>>> My 2 cents! >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/01/2016 10:23 AM, Rene Moser wrote: >>>>>>> >>>>>>>> Hi Remi >>>>>>>> >>>>>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote: >>>>>>>> >>>>>>>>> Maintaining LTS is harder than it seems. For example with upgrading. >>>>>>>>> You >>>>>>>>> can only upgrade to versions that are released _after_ the specific >>>>>>>>> LTS >>>>>>>>> version. This due to the way upgrades work. If you release 4.7.7 when >>>>>>>>> we’re >>>>>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same for 4.5: 4.5.4 >>>>>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply didn’t exist >>>>>>>>> when >>>>>>>>> these versions were released. (4.5.3 has been accounted for so that >>>>>>>>> does >>>>>>>>> work this time). If you want to keep doing 4.5 releases 18 months >>>>>>>>> from now, >>>>>>>>> that’s going to be a real issue. Users probably won’t understand and >>>>>>>>> expect >>>>>>>>> it to work. And yes, we will change the upgrading procedures but it’s >>>>>>>>> not >>>>>>>>> there yet. >>>>>>>>> >>>>>>>> Out of curiosity. I thought about patch relases like this scheme >>>>>>>> 4.5.2.x >>>>>>>> for LTS. This would work right? >>>>>>>> >>>>>>>> Regards >>>>>>>> René >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Ron Wheeler >>>>>>> President >>>>>>> Artifact Software Inc >>>>>>> email: rwhee...@artifact-software.com >>>>>>> skype: ronaldmwheeler >>>>>>> phone: 866-970-2435, ext 102 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ron Wheeler >>>>> President >>>>> Artifact Software Inc >>>>> email: rwhee...@artifact-software.com >>>>> skype: ronaldmwheeler >>>>> phone: 866-970-2435, ext 102 Find out more about ShapeBlue and our range of CloudStack related services: IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
