On Tue, Apr 24, 2018 at 3:46 PM, Eric Covener <cove...@gmail.com> wrote: >>> One thing you mention above is "wait for a new minor release". I can >>> definitely see that being an issue for our current maj.minor layout given >>> that minor bumps are measured in years. In this proposal, unless there's a >>> pressing need to send out a patch release right now, the next version WOULD >>> be that minor bump. Put into practice, I would see major bumps being >>> measured in years, minor bumps in quarters and patch bumps in weeks/months. > > I don't see how the minor releases would be serviceable for very long > there. If they're not serviceable, > then users have to move up anyway, then you're back at the status quo > with the dot in a different place.
I don't see where a version minor will be serviced for a particularly long time after the next minor is released *as GA*. So, if version 3.5.0 comes along and introduces some rather unstable or unproved code, and gets the seal of approval as -alpha... 3.5.1 is a bit better but has known bugs, it earns a -beta. Finally 3.5.2 is released as GA. In all of that time, I'd expect the project continues to fix defects is 3.4.x on a very regular basis, not expecting anyone to pick up 3.5 during that time. This is what substantially differs from using our least significant revision element for both minor and patch scope changes. If we adopt this as 3.0.0 to start; The 2.4.x users would continue to need security fixes for some time. When 4.0.0 was done in another decade, again 3.x.n users will be the ones needing help for some time. What the change accomplishes is that new development is never a gating factor of creating a patch release. Contrawise, reliable patch delivery is no longer a gating factor to new development. Each lives on its own track, and successful new development supersedes the previous version minor. Because of our conflation of patch and enhancement, the issue you had brought up, HttpProtocolOptions, occured "as a release". But I'd suggest that if 2.2 and 2.4 were each "major versions" (as users and developers understand that term), I would have submitted such a radical refactoring as a new version minor of each of those two flavors. Note that some of those actual changes would likely have occured some 4 years previous, when first proposed, had trunk not been removed from the release continuum for 6 years.
