Agree with the ideal world scenario :-) If we look at it from the other side: Why is it that people want to stay on older releases?
From personal experience I know that in the beginning the 4.4 release wasn’t that stable. I upgraded production systems from 4.3.0 to 4.4.2 and it was painful. That is not true anymore today, as 4.4.4 is pretty nice. From what I hear, 4.5.1 is also doing well. Great steps have been made already to make sure this will not happen again. Still, I can imagine that this may have scared some people and it made them stay where they are (at 4.3). Let’s investigate if people running 4.3 want to upgrade to 4.5.x or the upcoming 4.6 and, more important, why not? Then let’s fix that or prove it works. Regards, Remi > What is *our* plan :) > > We used to only maintain the last two major releases. > > We diverged from that model when 4.5.0 came out and that we still wanted to > maintain 4.3 because 4.3 was working so well for people. > > My personal preference would be to get into a rolling release model, where we > maintain only the last major release. > This is why making master stable and the base for all our releases is so > important. > > Users should get into a model where they continuously upgrade/deploy and > don't get stuck on a unmaintained branch with forks that prevents upgrade. > > When users face an issue, we patch and release, then they upgrade always to > the latest version. > > That's the ideal world :)