Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <druggeri@xxxxxxxxxxx> wrote:
> The more I think about it, the more I *really* like a semver-ish
> approach where major represents the ABI that will not be broken, minor
> represents the feature set (for backwards compatibility) and patch
> represents forward-compatible changes/fixes. This may be, in spirit,
> what you are suggesting. I'd further add that no directives are added in
> patch releases, but minor releases would be fair game. How we choose to
> maintain that behind the scenes is a thought exercise. Given that most
> of our users get httpd from distros, I'd be in favor of having only two
> long-lived branches: trunk and release. The distros are already taking
> the point-release they want and curating fixes/changes for it, so they
> will be doing what they do regardless of our direction.
Thought exercise... if it is decided that version 3.5.x added an all around
nice set of features, and we had platform maintainers as committers who
wanted to keep backporting to that tree at this project, well... they could
elect to maintain that version as a long lived branch and collaborate on
it while we went on our merry way through 3.15.0, even 4.1.x as a group.
In other words, wherever we have three committers who will cultivate a
long lived release, they can do that. This doesn't differ from how a few
individuals kept 2.0, and later, 2.2 alive for a significant period of time
after the next major release. When interest cooled, each was retired.