On 01/19/2017 03:57 PM, David Zuelke wrote:
Please no .micro releases. Most of the world is now trying to stick
to http://semver.org principles.
I agree with you, actually, but as you know, httpd is not on SemVer
currently and I'm not sure we can get there before 3.0. Maybe we'll all
agree on that tomorrow, but I doubt it.
Why not just keep 2.4 for maintenance, and start working on 2.6
immediately? Or 2.5?
Because discussions there are currently deadlocking, and I'm trying to
move pieces forward one bit at a time.
I honestly think that the current "odd numbers are unstable" approach
is not helpful with this whole situation. That's what betas and RCs
are for, and that gets you a more regular cadence in releases, which
helps with overall velocity.
Agreed... I'm not sure how it relates to my proposal, though.
HTTPD could even adopt a Debian/Ubuntu like policy, where there is a
new 2.next.0 every year or two, and whatever doesn't make the cut-off
date has to wait until the following iteration. That's been working
really well for PHP in recent years, too.
I think you and I are roughly on the same page on where we should
*eventually* be. But not everyone here is in agreement. I'm trying to
get a little bit of what I want here without making everyone else bend
over backwards.
All this proposal does, IMO, is just move the whole problem one
decimal point to the right.
Ignore the versioning number then; that's not really the core of my
proposal. The key points I'm making are
- introduce the concept of a low-risk release line
- formally tie said release lines to test suite expansion, in a way that
does not impede current contributors to 2.4.x
- introduce a stable cadence with as little risk to end users as possible
We can expand these concepts later if the other devs find that these are
useful things. One piece at a time.
--Jacob
