I believe having more minor releases and less major backports to patch releases is a good thing.
I believe we gave the even/odd, 2.1/2.3 "unstable", thing a long run. About 15 years of it. Since then the wider open source world has gone to a more canonical semver. I think we should generally align with that. <https://semver.org/> As an outcome, that would mean more major & minor releases, and less patch releases. I think that if we break an existing ABI, we need to bump the major. I think other projects are successfully doing this, and it has little effect on how distributions are packaging their projects. Distros pick a point in time, whatever the current major.minor.patch is. On Fri, Apr 20, 2018 at 5:04 AM, Micha Lenk <[email protected]> wrote: > Hi all, > > On 04/20/2018 01:34 PM, Jim Jagielski wrote: >> >> But why does it matter that h2 was added in 2.4.x instead of >> a 2.6.0? > > > Because it sets a bad precedence (or even continues to do so)? > >> Every new feature must bump the minor? Even if >> there is no corresponding ABI issue? > > > Why not? > > In my role as Debian Developer maintaining the Debian packages of other OSS > projects, and also in my role of maintaining a commercial reverse proxy > product based on Apache httpd during my day job, I value the ability to > distinguish between bugfix-only releases and feature addition releases. > > This does not mean that a minor bump needs to happen at almost every > release. But not bumping the minor for years (which seems to be the current > pattern of the httpd project) is just worse, because it increases the > incentive to squeeze features like h2 into releases that are meant (or > perceived) as bugfix-only releases. > > Regards, > Micha
