Re: Alternate versioning proposal: patch line releases
> On Jan 20, 2017, at 10:43 AM, Eric Covenerwrote: > > On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr > 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
On Fri, Jan 20, 2017 at 5:27 PM, William A Rowe Jrwrote: > On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener 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
On Fri, Jan 20, 2017 at 9:43 AM, Eric Covenerwrote: > > 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
On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jrwrote: > 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 cove...@gmail.com
Re: Alternate versioning proposal: patch line releases
On Thu, Jan 19, 2017 at 5:49 PM, Jacob Championwrote: > 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'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 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
On Fri, Jan 20, 2017 at 8:07 AM, Graham Leggettwrote: > On 20 Jan 2017, at 2:15 AM, Jacob Champion 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
On 20 Jan 2017, at 2:15 AM, Jacob Championwrote: > 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 — smime.p7s Description: S/MIME cryptographic signature
Re: Alternate versioning proposal: patch line releases
On 20.01.2017, at 02:00, Eric Covenerwrote: > > On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion 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
On Thu, Jan 19, 2017 at 6:49 PM, Jacob Championwrote: > 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 cove...@gmail.com
Re: Alternate versioning proposal: patch line releases
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
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 :)
Re: Alternate versioning proposal: patch line releases
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
I can even imagine a world where that makes sense...
Re: Alternate versioning proposal: patch line releases
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 Championwrote: > > 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'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 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'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