On Fri, Apr 20, 2018, 10:37 Paul Querna <p...@querna.org> wrote: > > 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.
According to my math and history here, which begins with binary stability (and not much feature changes in the period) at 1.3.14, and continuing throughout all of 2.0/2.2/2.4... Those would have been counted, using any semver scheme, as 2.0+++, 3.0+++, 4.0+++. Over the span of 18 years. That would put us at approaching 5.0.0, with discussion of refactoring how our URI's can successfully handle %CH entities correctly and finally close a group of (now mitigated but still broken) security issues. Mop up some other crufty bits in the process. Perhaps achieve 99.9% source compatibility with judicious use of compatibility macros. 2.0+ major revisions (ABI stable-ish) persisted over 6 years each. That isn't terribly shabby. Future majors would be even less frequent, as the framework proves durable. Pretend we are at 4.x, what would be our minor? I count only 21 releases in 2.4.x and 3 of those were immediate reactions to busted releases. That corresponds to releasing 4.17.1 in the span of 6 years. (I'm not suggesting renumbering, obviously... only trying to frame our project in semver terms to test if this would be helpful or harmful.) About 3 minor releases per year, and even that was perhaps too infrequent. The subversion bug-fix releases were certainly too infrequent, we shouldn't have waited so long on the fixes, but new development, and yes, refactoring also slow us down a lot. Thanks for the observations!
