You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jacob Champion <ch...@gmail.com> on 2017/01/19 23:49:14 UTC
Alternate versioning proposal: patch line releases
This is somewhat orthogonal to Bill's current suggestion. It solves a
different set of problems, more related to the short-term
features-versus-regressions argument and less related to the long-term
ABI arguments. Both are important to me, and I agree with many pieces of
what both Jim and Bill are saying.
(This is a combination of a bunch of different ideas from different
people, on this list and off, so thank you all for discussing.)
== Proposal ==
We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch
line. There are no new features or large code changes to this branch,
there are no refactorings or whitespace changes or huge cleanups; the
only changes that land here are targeted bug fixes to 2.4.25.
2.4.25.x is on a cadence: it's T&R'd like clockwork every month.
Releases from that line still follow the necessary voting procedure.
Meanwhile, once we decide we have enough new features for 2.4.26, we T&R
that. If 2.4.26 releases, and we decide we need some fixes, we spin up a
2.4.26.x branch and move to a cadence on it.
Requirements for a backport to the new low-risk 2.4.25.x branch:
- Your change must have landed in 2.4.x.
- Your change must be linked to a PR for a bug/regression.
- Your change is the smallest/simplest fix necessary (for some
definition of small/simple that your fellow voters agree with).
- You must have a test (or set of tests) committed to the test suite
that proves this change fixes the bug. (I.e. it fails before the change
and succeeds afterwards.)
Three votes are still required, and the commits to the test suite are
part of the voting review. If you can convince three other people that a
test is not worth the effort, you can override this requirement with an
additional vote (four total).
== Why? ==
The even-versus-odd, features-versus-regression idea seemed to have some
traction, but it means that fixes block features during an even release
and, to a certain extent, vice-versa during an odd release.
In this proposal, you have to really be serious about a bug fix to get
it into the patch line -- a double backport plus a mandatory addition to
the test suite -- but you're rewarded by knowing that your change *will*
be T&R'd within the month. And the next feature release won't be blocked
on fixes.
It gives us some emergency flexibility too. God forbid, say the 2.4.26
release introduces some absolute mayhem, we're deadlocked on some
breaking change or massive argument, users don't want to move to 2.4.26
and things are going nowhere fast for 2.4.27. Fine. 2.4.25.x is still
alive as long as there are enough PMC members interested in releasing
from it; the cadence only ends when we decide it does. The downside is
that we then have two parallel "latest" versions for 2.4.x, but if you
can convince three PMC members that this situation is better than being
frozen, so be it.
End users and maintainers should eventually feel, once we work out the
kinks, that the risk of upgrading to 2.4.x.y is never more than the risk
of upgrading to 2.4.x was. We should feel like our releases are never
frozen, even if we disagree about some major new feature -- we can
always fix stuff for users while we argue. The test suite will grow as
long as patch lines are released. And if it gets good enough, some day
far in the future, patch lines will become less and less necessary.
Thoughts?
--Jacob
Re: Alternate versioning proposal: patch line releases
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 20, 2017, at 10:43 AM, Eric Covener <co...@gmail.com> wrote:
>
> On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> Many if not most developers disagree with you, most developers agree that
>> adding features and enhancements is disruptive. 2.4.x adds features and
>> enhancements to every release, and is therefore not low-risk, and absolutely
>> not "as little risk as possible".
>
> Maybe a [POLL] thread is in order, specifically for the topic of
> enhancements/stability in 2.4 and ignoring aspirations about a new
> versioning system or 3.0.
>
> e.g.
>
> 2.4.x is:
> [X] evolving just fine
I'd like to see the new stuff currently "locked away" in trunk
get out to our end users. The only expedient way to do so lately
has been to backport to 2.4
If we could commit to releasing 2.6 in short order, then there
would not need to be the "demand" to backport as much.
Re: Alternate versioning proposal: patch line releases
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jan 20, 2017 at 5:27 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener <co...@gmail.com> wrote:
>>
>> Maybe a [POLL] thread is in order, specifically for the topic of
>> enhancements/stability in 2.4 and ignoring aspirations about a new
>> versioning system or 3.0.
>>
>> e.g.
>>
>> 2.4.x is:
>> [ ] evolving just fine
>> [ ] too unstable due to new features and we need to do something about it.
>> [ ] too unstable due to code/review/test escapes and we need to do
>> something about it.
I wouldn't how to vote with this one, "evolving not as fast as I'd
like" and "quite stable" is my opinion...
>
>
> One possible poll;
>
> New features/enhancements;
> [ ] belong on 2.4.x
> [ ] should be released as 2.5.0
I like this one, for now :)
(nothing better to propose...)
Re: Alternate versioning proposal: patch line releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener <co...@gmail.com> wrote:
>
> Maybe a [POLL] thread is in order, specifically for the topic of
> enhancements/stability in 2.4 and ignoring aspirations about a new
> versioning system or 3.0.
>
> e.g.
>
> 2.4.x is:
> [ ] evolving just fine
> [ ] too unstable due to new features and we need to do something about it.
> [ ] too unstable due to code/review/test escapes and we need to do
> something about it.
Perhaps too many choices?
One possible poll;
New features/enhancements;
[ ] belong on 2.4.x
[ ] should be released as 2.5.0
An entirely different possible poll;
[Multiple Choice - pick two(?) top issues] Apache HTTP Server is lacking in
[ ] new features and enhancements
[ ] code quality
[ ] code review
[ ] test scripts
[ ] contributors
[ ] documentation
[ ] cooperation
Cross pollinating a poll with multiple a/b decision points (is it good/bad,
should we solve x/y) dilutes the chance to work out root causes and
to work out potential solutions. "Do something about it" is a particularly
silly question, since committers will focus on what they want to focus
on, there is no ASF script for "tell people what to work on."
And of course, a new thread Subject: to whatever poll someone wants
to run. I don't plan to submit a poll, I'm just working from all individuals'
responses to these several threads to determine where we sit on the
whole spectrum of rapid updates vs version stability, to base any formal
proposal and [vote] later on. I particularly don't care where 2.4.x goes,
I'm more interested in agreeing to a process and moving on.
Re: Alternate versioning proposal: patch line releases
Posted by Eric Covener <co...@gmail.com>.
On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Many if not most developers disagree with you, most developers agree that
> adding features and enhancements is disruptive. 2.4.x adds features and
> enhancements to every release, and is therefore not low-risk, and absolutely
> not "as little risk as possible".
Maybe a [POLL] thread is in order, specifically for the topic of
enhancements/stability in 2.4 and ignoring aspirations about a new
versioning system or 3.0.
e.g.
2.4.x is:
[ ] evolving just fine
[ ] too unstable due to new features and we need to do something about it.
[ ] too unstable due to code/review/test escapes and we need to do
something about it.
--
Eric Covener
covener@gmail.com
Re: Alternate versioning proposal: patch line releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Jan 20, 2017 at 8:07 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 20 Jan 2017, at 2:15 AM, Jacob Champion <ch...@gmail.com> wrote:
>
>> 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
>
> We have always had this, the current low-risk release line is called v2.4.x.
>
>> - introduce a stable cadence with as little risk to end users as possible
>
> We have always had this.
Many if not most developers disagree with you, most developers agree that
adding features and enhancements is disruptive. 2.4.x adds features and
enhancements to every release, and is therefore not low-risk, and absolutely
not "as little risk as possible".
C.f. para 4; https://en.wikipedia.org/wiki/Software_versioning#Change_significance
Re: Alternate versioning proposal: patch line releases
Posted by Graham Leggett <mi...@sharp.fm>.
On 20 Jan 2017, at 2:15 AM, Jacob Champion <ch...@gmail.com> wrote:
> 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
We have always had this, the current low-risk release line is called v2.4.x.
> - formally tie said release lines to test suite expansion, in a way that does not impede current contributors to 2.4.x
We have always had this. The test suite is called httpd-test and covers all versions of httpd.
> - introduce a stable cadence with as little risk to end users as possible
We have always had this.
Regards,
Graham
—
Re: Alternate versioning proposal: patch line releases
Posted by Jacob Champion <ch...@gmail.com>.
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
Re: Alternate versioning proposal: patch line releases
Posted by David Zuelke <dz...@heroku.com>.
Please no .micro releases. Most of the world is now trying to stick to http://semver.org principles.
Why not just keep 2.4 for maintenance, and start working on 2.6 immediately? Or 2.5?
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.
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.
All this proposal does, IMO, is just move the whole problem one decimal point to the right.
On 20.01.2017, at 00:49, Jacob Champion <ch...@gmail.com> wrote:
>
> This is somewhat orthogonal to Bill's current suggestion. It solves a different set of problems, more related to the short-term features-versus-regressions argument and less related to the long-term ABI arguments. Both are important to me, and I agree with many pieces of what both Jim and Bill are saying.
>
> (This is a combination of a bunch of different ideas from different people, on this list and off, so thank you all for discussing.)
>
> == Proposal ==
>
> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line. There are no new features or large code changes to this branch, there are no refactorings or whitespace changes or huge cleanups; the only changes that land here are targeted bug fixes to 2.4.25.
>
> 2.4.25.x is on a cadence: it's T&R'd like clockwork every month. Releases from that line still follow the necessary voting procedure. Meanwhile, once we decide we have enough new features for 2.4.26, we T&R that. If 2.4.26 releases, and we decide we need some fixes, we spin up a 2.4.26.x branch and move to a cadence on it.
>
> Requirements for a backport to the new low-risk 2.4.25.x branch:
> - Your change must have landed in 2.4.x.
> - Your change must be linked to a PR for a bug/regression.
> - Your change is the smallest/simplest fix necessary (for some definition of small/simple that your fellow voters agree with).
> - You must have a test (or set of tests) committed to the test suite that proves this change fixes the bug. (I.e. it fails before the change and succeeds afterwards.)
>
> Three votes are still required, and the commits to the test suite are part of the voting review. If you can convince three other people that a test is not worth the effort, you can override this requirement with an additional vote (four total).
>
> == Why? ==
>
> The even-versus-odd, features-versus-regression idea seemed to have some traction, but it means that fixes block features during an even release and, to a certain extent, vice-versa during an odd release.
>
> In this proposal, you have to really be serious about a bug fix to get it into the patch line -- a double backport plus a mandatory addition to the test suite -- but you're rewarded by knowing that your change *will* be T&R'd within the month. And the next feature release won't be blocked on fixes.
>
> It gives us some emergency flexibility too. God forbid, say the 2.4.26 release introduces some absolute mayhem, we're deadlocked on some breaking change or massive argument, users don't want to move to 2.4.26 and things are going nowhere fast for 2.4.27. Fine. 2.4.25.x is still alive as long as there are enough PMC members interested in releasing from it; the cadence only ends when we decide it does. The downside is that we then have two parallel "latest" versions for 2.4.x, but if you can convince three PMC members that this situation is better than being frozen, so be it.
>
> End users and maintainers should eventually feel, once we work out the kinks, that the risk of upgrading to 2.4.x.y is never more than the risk of upgrading to 2.4.x was. We should feel like our releases are never frozen, even if we disagree about some major new feature -- we can always fix stuff for users while we argue. The test suite will grow as long as patch lines are released. And if it gets good enough, some day far in the future, patch lines will become less and less necessary.
>
> Thoughts?
>
> --Jacob
Re: Alternate versioning proposal: patch line releases
Posted by Jim Jagielski <ji...@apache.org>.
I can even imagine a world where that makes sense...
Re: Alternate versioning proposal: patch line releases
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 19, 2017 at 5:49 PM, Jacob Champion <ch...@gmail.com> wrote:
> This is somewhat orthogonal to Bill's current suggestion. It solves a
> different set of problems, more related to the short-term
> features-versus-regressions argument and less related to the long-term ABI
> arguments. Both are important to me, and I agree with many pieces of what
> both Jim and Bill are saying.
>
> (This is a combination of a bunch of different ideas from different people,
> on this list and off, so thank you all for discussing.)
>
> == Proposal ==
>
> 2.4.25.x is on a cadence: it's T&R'd like clockwork every month. Releases
> from that line still follow the necessary voting procedure. Meanwhile, once
> we decide we have enough new features for 2.4.26, we T&R that. If 2.4.26
> releases, and we decide we need some fixes, we spin up a 2.4.26.x branch and
> move to a cadence on it.
This is the OpenSSL model which httpd effectively mirrors today, although
their .x is an alpha sequence, and your proposal could be read with either
semantic.
However, OpenSSL changes very little in terms of it's scope, and isn't the
best model for an evolutionary, development driven project like httpd.
1.0.0 and 1.1.0 both refactored much of the API in terms of opacity of internal
data members.
1.0.0, 1.0.1, 1.0.2 were incremental TLS features, but as these were defined
by spec, the scope of those upgrades was clear.
So I'd anticipate 1.1.1 if the API is extended further for new TLS features
without other changes, or I'd anticipate 1.2.0 if the API will be further
refactored (or both.)
But given the amount of recoding required to migrate from 1.0.x -> 1.1.0,
as illustrated by a bunch of patches here for mod_ssl, most modern
developers would have considered that rework a 2.0 scope change.
At least the OpenSSL project accomplishes what you outlined above,
irrespective of their number-alpha'ing schema.
Re: Alternate versioning proposal: patch line releases
Posted by David Zuelke <dz...@heroku.com>.
On 20.01.2017, at 02:00, Eric Covener <co...@gmail.com> wrote:
>
> On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion <ch...@gmail.com> wrote:
>> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line.
>> There are no new features or large code changes to this branch, there are no
>> refactorings or whitespace changes or huge cleanups; the only changes that
>> land here are targeted bug fixes to 2.4.25.
>
> My fear here is that nearly nobody would ever end up using these patch
> line releases, but we'd probably never know for sure.
Or adopt them, but never move off them,
And the other question then becomes... for how long will that particular patch version receive updates? Or even backports of fixes that are much harder than in a newer version? How many patch release series are allowed to exist at the same time?
Etc etc. I think this would turn into a huge burden, and cause confusion for users.
Re: Alternate versioning proposal: patch line releases
Posted by Eric Covener <co...@gmail.com>.
On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion <ch...@gmail.com> wrote:
> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line.
> There are no new features or large code changes to this branch, there are no
> refactorings or whitespace changes or huge cleanups; the only changes that
> land here are targeted bug fixes to 2.4.25.
My fear here is that nearly nobody would ever end up using these patch
line releases, but we'd probably never know for sure.
Meanwhile, we probably won't do a great job at actually excluding the
stuff that we'd later learn is detrimental.
As I just said in the other thread, it might make more sense to split
2.4/2.6 now w/o the usual bumps so there is a non trunk release for
people to innovate in relatively safely (new mods, new opt-in
features, etc). Right now the lack of another option contributes to
the "other" trunk issue as a testbed that doesn't see much testing and
ages longer then it should.
--
Eric Covener
covener@gmail.com
Re: Alternate versioning proposal: patch line releases
Posted by Jacob Champion <ch...@gmail.com>.
On 01/19/2017 04:25 PM, Stefan Sperling wrote:
> On Thu, Jan 19, 2017 at 03:49:14PM -0800, Jacob Champion wrote:
>> We branch off from the 2.4.25 tag.
>
> I am not sure you mean this literally, but anyway:
I mean that the 2.4.25.x branch starts from the commit that we tagged as
2.4.25. That's all. (Sorry, most of the branching terminology I'm using
comes from the git model, which I use locally.)
--Jacob
Re: Alternate versioning proposal: patch line releases
Posted by Stefan Sperling <st...@stsp.name>.
On Thu, Jan 19, 2017 at 03:49:14PM -0800, Jacob Champion wrote:
> We branch off from the 2.4.25 tag.
I am not sure you mean this literally, but anyway:
While basing a branch off of a tag (svn copy ^/tags/foo ^/branches/newbranch)
works, I would recommend to always create a branch first, and then copy that
branch to a tag. And then use this branch as destination for future patches,
and as the copy source of tags representing future releases.
So you would perform svn copies like this:
svn copy ^/trunk ^/branches/2.4.x
svn copy ^/branches/2.4.x ^/branches/2.4.25.x
svn copy ^/branches/2.4.25.x ^/tags/2.4.25.0
# work on 2.4.25.x branch
svn copy ^/branches/2.4.25.x ^/tags/2.4.25.1
# work on 2.4.25.x branch
etc.
The reason is that this way, all tags have copyfrom info pointing back
to the branch they are derived from, and there is no special case where
a tag suddenly becomes the copy source of a branch. This choice affects
both the repository structure as well as the arguments people would be
passing to svn copy to perform one of these steps.
That said, this is mosly a cosmetic concern. The other way *should*
work since SVN is always just dealing with copies.
But I'm a tiny bit annoyed that SVN allows it :)