On Wed, Apr 25, 2018 at 1:50 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > 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.
Thanks Bill. This aspect does look helpful.
