thanks Remi, I think I we agree. On Mon, Jan 11, 2016 at 4:16 PM, Remi Bergsma <rberg...@schubergphilis.com> wrote:
> Guys, > > IMHO we should pick 4.7 instead of 4.6 as it has newer features (like the > Metrics UI and some more stuff). Apart from that 4.7 has had more bug > fixes. These could have been merged to 4.6, but we didn’t always do that. > Let’s make sure we keep doing that for 4.7, also when 4.8 is out. Apart > from that 4.7.0 == 4.6.2. If one upgrade is easy, it’s 4.6.2 to 4.7.0 so > let’s not bother. Pick 4.7, it’s better. Trust me. > > I also say, should we want to do something LTS-like, we pick a branch, aka > '4.7’, rather than a specific version like ‘4.7.1’ etc. Don’t see how we > could LTS a single version. > > 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. > > I do understand people want to make 4.5 LTS instead of a more recent > version. Except for the above, it’s doable. It’s a lot of extra work, but > if people feel it’s worth it they can of course do it. Rohit for example > also maintained 4.3 for a long time. Pre-4.6 back porting was the way to > go, so you can continue to do that. From 4.6, the workflow is based on > forward-merging, as Daan explained so no cherry-picking there. > > Generally speaking, I don’t like it when people have a strong opinion on > something and they don’t work on it themselves. So, as I probably won’t be > working on LTS releases, I won’t -1 it for this reason. I'm just trying to > help understand what it’d be like. > > Regards, > Remi > > > > > On 11/01/16 14:47, "Sebastien Goasguen" <run...@gmail.com> wrote: > > > > >> On Jan 11, 2016, at 2:41 PM, Nux! <n...@li.nux.ro> wrote: > >> > >> Daan, > >> > >> Ok, that sounds good, but at this point it's really up to the people > writing actual code. > >> Wido has already voted against it and SBP guys don't seem too keen on > it either. > >> > > > >Exactly, we can say we want an LTS, but then we need a RM. > > > >and FWIW, I would think we want to LTS starting with 4.6.2. > > > >We need to make sure all upgrade to 4.6.2 work and start there. > > > >The reason being that subsequent upgrade and LTS maintenance should be > much easier as the upstream ( 4.7+) gets the benefit of the new workflow. > > > > > > > > > >> -- > >> Sent from the Delta quadrant using Borg technology! > >> > >> Nux! > >> www.nux.ro > >> > >> ----- Original Message ----- > >>> From: "Daan Hoogland" <daan.hoogl...@gmail.com> > >>> To: "dev" <dev@cloudstack.apache.org> > >>> Sent: Monday, 11 January, 2016 13:36:06 > >>> Subject: Re: LTS release or not > >> > >>> Any version that is not a year old should be LTS in my view. We must as > >>> reviewers take care that fixes are merged on the oldest branch first > and > >>> then merged forward along the line. To me this was the whole purpose > of the > >>> changes we did to our release process. Are we abandonning this now to > >>> return to fixing on seperate branches and have the same fix in multiple > >>> commitishes? Excuse my Dutch: That sucks. > >>> > >>> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <n...@li.nux.ro> wrote: > >>> > >>>> I think LTS is a good idea, but I am afraid we'd be spreading > ourselves > >>>> too thin with maintaining that in addition to mainline. > >>>> > >>>> The way I see it, one way to have this sorted is by means of > commercial > >>>> offerings from companies such as ShapeBlue. > >>>> > >>>> What lifetime are we talking rougly for an LTS release? 6 months, 12 > >>>> months? > >>>> > >>>> Lucian > >>>> > >>>> -- > >>>> Sent from the Delta quadrant using Borg technology! > >>>> > >>>> Nux! > >>>> www.nux.ro > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Daan Hoogland" <daan.hoogl...@gmail.com> > >>>>> To: "dev" <dev@cloudstack.apache.org> > >>>>> Sent: Monday, 11 January, 2016 13:19:48 > >>>>> Subject: Re: LTS release or not > >>>> > >>>>> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <m...@renemoser.net> > wrote: > >>>>> > >>>>>>>> * Fix must be important. > >>>>>>>> > >>>>>>> > >>>>>>> Who defines what 'important' is? > >>>>>> > >>>>>> "must be important" means we do not backport trivial things like > typos > >>>>>> in docs and so forth, only important things. And I would say > important > >>>>>> in a common sense. But it doesn't mean that all important fixes > will be > >>>>>> backportable, because they may not be necessary "obvious and small". > >>>>>> > >>>>> > >>>>> if it is really important it should be fixed on the LTS first and > then > >>>>> merged to 'bleeding edge' if still applicable. > >>>>> > >>>>> Limitation of warranty: I really don't like this discussion as it > >>>> negates > >>>>> most of the hard weekend work I did over the last half year. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Daan > >>>> > >>> > >>> > >>> > >>> -- > >>> Daan > > > -- Daan
