On Jul 2, 2015, at 4:58 PM, Remi Bergsma <r...@remi.nl> wrote: > Bug fixing in older releases is actually a lot of work. For security related > issues we could maybe do it. > > Personally, I prefer to have a fast release cycle and smooth (tested) upgrade > paths over 2-year LTS release cycle. It's more agile. As a bonus, people get > the new features. > > The more people do upgrades that work (tm) the more confident they are. I'd > really want to show that upgrades work so well that we need no LTS. > > But there might be other reasons people have where LTS would help. Please > share! > > Regards, Remi
I think we got in a situation with 4.4 that called for us to keep maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a good release. Now that we have 4.4 and 4.5.2 etc, I don't think we will have the cycles to maintain that many release branches. The big issue is upgrade path, IMHO our LTS strategy is to have master as a release branch itself, adopt good practice to merge to master, have great upgrades and no regressions. Ultimately we should divert our efforts to master. So I am +1 with Remi on this. > > >> On 02 Jul 2015, at 16:25, Rene Moser <m...@renemoser.net> wrote: >> >> Maybe a little bit off topic to the new release process, therefor a new >> thread... >> >> speaking about releases. I just thought about supporting LTS releases. >> >> This would mean "someone" or "we" make a commitment to add bug fixes >> (only) for a specified time. e.g. 2 years for a release or until the >> next LTS release? >> >> Would this something anyone would be interested in? >> >> Yours >> René
