Re: A proposal...
On Tue, Apr 24, 2018 at 3:46 PM, Eric Covener <covener@xxxxxxxxx> 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.