On 04/15/2018 03:25 AM, Yehuda Katz wrote: > On Sat, Apr 14, 2018 at 9:48 AM, Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: > > IMO, the below ignores the impacts on OS distributors who > provide httpd. We have seen how long it takes for them > to go from 2.2 to 2.4... I can't imagine the impact for our > end user community if "new features" cause a minor > bump all the time and we "force" distributions for > 2.4->2.6->2.8->2.10... > > Just my 2c > > > That also assumes the OS distributions pick up the point releases. RedHat > certainly doesn't pick up the new features, > only bug fixes.
But in this case users of those binaries shouldn't be affected by the regressions as they only receive bug fix backports :-P. Seriously, we also had regressions just in bug fixes and the feature backporting makes it sometimes harder to correctly backport pure bug fixes for these distributions as the code changes are bigger in the stable branch because of the feature backports. Of course this is not our direct issue and main concern here. One idea that comes to my mind is whether we should have an "LTS" version that only receives bugfixes and another "stable" branch that receives new feature (on the same level of API compatibility we currently grant for our stable branches). E.g. you could go with a major release X.Y.0.Z and after some minor releases Z which still allow feature and bugfixes to be backported in an API compatible way (to give the new major some time to stabilize) split of X.Y.1.Z to allow feature backports in an API compatible way and allow only bug fix backports to X.Y.0.Z. Questions that pop up with this are: 1. Is there enough manpower and willingness to maintain this? 2. How will the commercial 3rd parties handle this? Will they only support X.Y.0.Z or will they also support X.Y.1.Z? From an API point of view it doesn't matter as X.Y.0 and X.Y.1 follow the same API guarantee. X.Y.1 just has a bigger regression risk. Other typical suspects are: 1. Improve testing suite(s). 2. Give the future release a broader real life testing exposure. The question is how we can get to this. I am not sure if RC release will help here, because it requires a sufficient amount of people to use and test them. Seeing RC on a release might make them saying: Nah, let others do that testing I will wait until RC is gone and take it then. So I am not sure if RC releases will improve the exposure compared to the current exposure during the voting. If it is just a matter of time (voting usually "only" takes 72 hours, compared to a RC release which would be around longer before the next RC or final release) it could help indeed. Sorry for the rant. Regards Rüdiger
