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)])

[William A Rowe Jr]

On Tue, Apr 24, 2018 at 6:36 AM, Daniel Ruggeri  wrote:
>
> One more thing to point out that I didn't explicitly say in the previous 
> message is that this suggestion implies the release branch regularly gets cut 
> from trunk (rather than growing and diverging on its own). This helps avoid 
> "locking" features in trunk indefinitely because of the time between Maj.Min 
> bumps.

+1... the new development branch has the greatest activity level. Any patch
branch is picked from that current activity.

Any major rev refactoring should be proven up in a sandbox first. If it can
be automated (e.g. function renames or mass function updates as we had
for APLOGNO()), all the better to test and re-test against trunk.

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)])

[Daniel Ruggeri]

On April 23, 2018 11:30:07 AM CDT, William A Rowe Jr  
wrote:
>On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri 
>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.

Of course - this being Open Source and we being volunteers, we work on what we 
want to work on :-). I generally see that doesn't happen much for projects 
operating this way, though. My perception is that typically once 2.7.0 is 
released, work dies off quickly for 2.6.x. As mentioned elsethread, what the 
distros are signing up for (right or wrong) is to put a stake in the ground on 
a certain version and to select specific patches for fixes alone. If we were to 
do the same, it may be a duplication of effort.

Now... That doesn't preclude us from operating like Ubuntu does, for example, 
with their LTS style releases where we do "2.6.x will get fixes only for X 
years, but 2.7+ will get features until the next LTS cut". I think that idea 
may be what you have in mind. So, in that world we have three long lived 
branches: trunk, release and LTS. I can see us operating in that way... and to 
make backports less cumbersome, we could further declare that a fix accepted in 
STATUS for the LTS branch is accepted also into the release branch.

One more thing to point out that I didn't explicitly say in the previous 
message is that this suggestion implies the release branch regularly gets cut 
from trunk (rather than growing and diverging on its own). This helps avoid 
"locking" features in trunk indefinitely because of the time between Maj.Min 
bumps.
-- 
Daniel Ruggeri

Re: Start using RCs

[Micha Lenk]

On 04/23/2018 07:24 PM, Paul Querna wrote:

https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

Contains a much more verbose... non-semver versioning scheme.


Interesting. Did you realize this already covers the recently suggested 
use of release candidates? Even on the 2.4.x branch...


Regards,
Micha

Re: Start using RCs

[Paul Querna]

On Mon, Apr 23, 2018 at 10:10 AM, Micha Lenk  wrote:
> On 04/23/2018 06:33 PM, William A Rowe Jr wrote:
>>
>> On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk  wrote:
>>>
>>> On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:

 We have a history, as well as a published "agreement" on what minor
 version numbering means.
>>>
>>>
>>> Just to make sure I am on the same page, would you mind to make that
>>> explicit? Where is that published?
>>
>>
>> http://httpd.apache.org/dev/release.html
>
>
> The only paragraph on that page that contains the word "minor" is the second
> one in the Introduction section. It isn't very verbose either. Am I missing
> something obvious?
>
> Regards,
> Micha

https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

Contains a much more verbose... non-semver versioning scheme.

Re: Start using RCs

[Micha Lenk]

On 04/23/2018 06:33 PM, William A Rowe Jr wrote:

On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk  wrote:

On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:

We have a history, as well as a published "agreement" on what minor
version numbering means.


Just to make sure I am on the same page, would you mind to make that
explicit? Where is that published?


http://httpd.apache.org/dev/release.html


The only paragraph on that page that contains the word "minor" is the 
second one in the Introduction section. It isn't very verbose either. Am 
I missing something obvious?


Regards,
Micha

Re: Start using RCs

[William A Rowe Jr]

On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk  wrote:
> Hi Jim,
>
> On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:
>> We have a history, as well as a published "agreement" on what minor
>> version numbering means.
>
> Just to make sure I am on the same page, would you mind to make that
> explicit? Where is that published?

http://httpd.apache.org/dev/release.html

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)])

[William A Rowe Jr]

On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri  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.

Re: Start using RCs

[Micha Lenk]

Hi Jim,

On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:
> We have a history, as well as a published "agreement" on what minor
> version numbering means. 

Just to make sure I am on the same page, would you mind to make that
explicit? Where is that published?

> Our module eco-system is huge and we need to factor/consider not only
> the big players, but also the solitary developers who have modules. It
> is a long, long history and if/when we need to reconsider versioning,
> the impact will not be insignificant.
>
> [...]
> Again, it is all in balance, and likely we've just not achieved that
> lately due to the extreme complexities of the eco-system around,
> internal, external and dependent upon us.

But isn't the very purpose of the major.minor construct (that renders
all modules incompatible on a minor version bump) to get a handle on the
"extreme complexity" of the eco-system? If so, is the major.minor
construct used correctly to get the most out of it?

Regards,
Micha

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)])

[Greg Stein]

On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri 
wrote:

> Yeah - I think my main concern is really just around the backporting
> process with STATUS and how that will have issues scaling across many
> branches. Further, as each branch deviates, it becomes more of a
> cognitive exercise for developers to figure out if the fix in branch XYZ
> is applicable and the same in ABC.
>
> 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.


Apache Subversion takes the patch number much more literally. They are
merely fixes to behavior defined in the minor release. The API/ABI is never
touched during a patch release. You could build against 1.7.13, then
install 1.7.0 and your code works against it. Then upgrade svn to 1.7.20
and it still works. Downgrade to 1.7.5 ... you get the picture.

I see several issues with the recent threads of discussion:

* How releases are numbered, and what guarantees are made relative to those
numbers
* What kinds of gating of features/fixes is defined by the process?
* How are branches created/maintained, relative to the above

Classic httpd numbering can certainly be made to work (empirically: it
has). semver is well-documented, understood, and downstream users would not
need to understand our quirks. It does kind of impose decisions on gating
of features, though (Q2 above).

It is unclear what problem is being solved. It seems like the unpredictable
feature set of 2.4.x. And/or when to stop loading features into that, and
start a 2.6.x series. (or 3.0?)

Cheers,
-g

ps. my vote is for semver and strict controls on patch releases. chew
through release numbers. they are cheap. downstream will pick one release
and run with that. it doesn't matter to them if we have a new minor every
six months (which means new features, which distros won't pick those
features from patch releases anyways; may as well move them to a minor)

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)])

[Eric Covener]

On Sun, Apr 22, 2018 at 2:03 PM, Daniel Ruggeri  wrote:
> Unhelpful for whom? If we ship the latest, secure config from the single 
> release branch, we wouldn't be encumbered by having to use tricks for fixes.

I think we're getting off into the weeds a bit here.  My belief is
that most users extend the configuration, and different users want
different behaviors even if they use the same distribution.  Most
users  at any given time want no changes at all beyond the required
security fixes.

I don't feel like "directives" are even a secondary source of any of
the recent regressions. In reality, gating changes behind directives
would have likely avoided a good deal of the regressions if we had a
different tolerance for such a thing or the impacts could have been
anticipated.

That's why I don't see any benefit in prohibiting new directives in a
reworked service stream being managed as more stable, even without
weighing any of the other tradeoffs. I see only risk in that fixes can
only be delivered when they are safe for 100% of users 100% of the
time.

> In the same vein of thought, if it is disruptive to a config, that signals a 
> minor bump. Patch changes must be forward compatible.

This doesn't really differ from the status quo.

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)])

[Graham Leggett]

On 19 Apr 2018, at 5:11 PM, Jim Jagielski  wrote:

> With all this in mind, should we try to set things up so that the
> next release cycle uses the concept of RCs?
> 
> If so, and if people like, I can come up with a baseline
> proposal on the process for us to debate and come to
> some consensus on.

What specific problem does this aim to solve?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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)])

[Daniel Ruggeri]

Unhelpful for whom? If we ship the latest, secure config from the single 
release branch, we wouldn't be encumbered by having to use tricks for fixes. 
Most end users who get their custom build from the distros would get the same 
custom directive-level fixes applicable to them (ie:  they know what's in the 
build so don't have to do such gymnastics).

In the same vein of thought, if it is disruptive to a config, that signals a 
minor bump. Patch changes must be forward compatible.
-- 
Daniel Ruggeri

On April 22, 2018 12:32:24 PM CDT, Eric Covener  wrote:
>On Sun, Apr 22, 2018 at 1:31 PM, Eric Covener 
>wrote:
>>> I'd further add that no directives are added in
>>> patch releases, but minor releases would be fair game.
>>
>> I don't think that kind of rule would be helpful, it just pushes
>> configuration into defines, per-request environment variables, etc
>> which are worse (because unlike a directive, you can't tell if
>they're
>> present)
>
>Of fixes which may be disruptive, that is.

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)])

[Eric Covener]

On Sun, Apr 22, 2018 at 1:31 PM, Eric Covener  wrote:
>> I'd further add that no directives are added in
>> patch releases, but minor releases would be fair game.
>
> I don't think that kind of rule would be helpful, it just pushes
> configuration into defines, per-request environment variables, etc
> which are worse (because unlike a directive, you can't tell if they're
> present)

Of fixes which may be disruptive, that is.

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)])

[Eric Covener]

> I'd further add that no directives are added in
> patch releases, but minor releases would be fair game.

I don't think that kind of rule would be helpful, it just pushes
configuration into defines, per-request environment variables, etc
which are worse (because unlike a directive, you can't tell if they're
present)

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)])

[Daniel Ruggeri]

Yeah - I think my main concern is really just around the backporting
process with STATUS and how that will have issues scaling across many
branches. Further, as each branch deviates, it becomes more of a
cognitive exercise for developers to figure out if the fix in branch XYZ
is applicable and the same in ABC.

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. For
administrators building httpd themselves, they have control of when to
pull the trigger on a build and what they build, so I don't think they
would be harmed by such a change. Hopefully this isn't considered a
caustic statement (it is not intended to be), but I feel that this would
bring our versioning practices more in line with what most OSS projects
are doing these days and also avoid some of the issues managing several
branches. (I really am digging this idea :-) I'm glad folks have
proposed it...)

-- 
Daniel Ruggeri

On 4/20/2018 12:08 AM, William A Rowe Jr wrote:
> Let me counter with this... Rather than break the API every m.n
> release, what if we roll on to 2.6 with no ABI breakage, or resolve
> with impumity everything wrong in 3.0 with a firm commitment not to
> break it again till 4.0?
>
> This might be the root problem of our trying to !is versioning semantics.
>
>
> On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri  > wrote:
>
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd
> expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a
> release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches
> and a
> bugfix applicable to all (or worse... a security fix that would
> dictate
> all should be released/disclosed at the same time).
>
> -- 
> Daniel Ruggeri
>
> On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> > I don't disagree with RC's entirely, or the mechanism you
> suggest, but
> > that isn't what I read as proposed.
> >
> > Our issue is that every httpd must be distinguished, we won't ship
> > four tarballs all claiming 2.4.34 (GA). Which one is the person
> > complaining about? Are we back to SHA signature of the source
> tarball
> > (that isn't even assuredly what they built the binary from?)
> >
> > We can decorate the rc in the versioning, but that isn't part of
> 2.4.x
> > API, unless we swap out the "-dev" string tag for an "-rc#" value.
> >
> > It is not reasonable to lock a branch for an indeterminate length of
> > time. Branching the RC into what becomes the final release, and
> making
> > it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> > might help discourage disruptive backports, but there is no
> suggestion
> > yet of what is acceptable, either on such a frozen main branch or rc
> > branch.
> >
> > In fact our policy reflects that two competing release candidates is
> > an entire valid and even expected situation, and any process that
> > further blocks this should be firmly rebuffed.
> >
> > As it reads so far the proposal is the way we do things, now
> > conserving subversion numbers as precious, if only to reenforce a
> > stake in the ground that version major and minor numbers are
> similarly
> > precious, (which they are not.)
> >
> > With the addition of freezing changes on 2.4.x branch for a time we
> > succeed in impeading progress towards version .next, while not
> > otherwise changing the status quo.
> >
> > What you suggest is yet another thing, based on forking the RC
> release
>  

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)])

[Jim Jagielski]

> On Apr 20, 2018, at 8:28 AM, Micha Lenk  wrote:
> 
> Hi Jim,
> 
> On 04/20/2018 01:46 PM, Jim Jagielski wrote:
>> Where numbers and versioning DOES matter is how it affects
>> distributors and vendors of httpd and the entire module eco-system.
> No, it doesn't. There are way too many variants of versioning schemes out 
> there in use by so many OSS projects that the distributors and vendors need 
> to be prepared to encounter any variant you can imagine.
> 

We have a history, as well as a published "agreement" on what minor version 
numbering means. Our module eco-system is huge and we need to factor/consider 
not only the big players, but also the solitary developers who have modules. It 
is a long, long history and if/when we need to reconsider versioning, the 
impact will not be insignificant.

> What matters is quality (here I do agree with you). A versioning scheme can 
> help to establish certain rules of what to do and more importantly what to 
> *not* do on a given version pattern or branch. And with the current rate of 
> successful releases, apparently the current rules either were not enforced 
> well enough or otherwise were not good enough and thus need to be changed. A 
> new versioning scheme then could help to establish new, hopefully better 
> rules.

Or just change the goalposts... if, as you say, our current version-scheme 
rules don't work as far as limiting/controlling what we can do (which I don't 
agree with, btw), then simply replacing it with another version-scheme likely 
won't do anything as well.

Again, I don't think numbers or names are the issue at hand, at core, but 
rather, maybe, overconfidence in how we have been doing release QA and testing. 
For example, and I am certainly guilty of this, the original concept was that 
"new stuff" was put in trunk, and allowed to mellow and age, for a "bit" at 
least, to get a feel for how well it works. After "awhile", when things looked 
like it was "ready for prime time", it would be proposed for backport. Today, 
right after something is committed to trunk there is almost invariably, in the 
next commit, a backport proposal for it to be in 2.4. Now for bug fixes, etc, 
that likely makes some level of sense, but lately, it seems like committing to 
trunk is just a tic-mark.

Again, it is all in balance, and likely we've just not achieved that lately due 
to the extreme complexities of the eco-system around, internal, external and 
dependent upon us.

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)])

[Micha Lenk]

Hi Jim,

On 04/20/2018 01:46 PM, Jim Jagielski wrote:

Where numbers and versioning DOES matter is how it affects
distributors and vendors of httpd and the entire module eco-system.
No, it doesn't. There are way too many variants of versioning schemes 
out there in use by so many OSS projects that the distributors and 
vendors need to be prepared to encounter any variant you can imagine.


What matters is quality (here I do agree with you). A versioning scheme 
can help to establish certain rules of what to do and more importantly 
what to *not* do on a given version pattern or branch. And with the 
current rate of successful releases, apparently the current rules either 
were not enforced well enough or otherwise were not good enough and thus 
need to be changed. A new versioning scheme then could help to establish 
new, hopefully better rules.


Just my 2¢.

Regards,
Micha

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)])

[Jim Jagielski]

> On Apr 20, 2018, at 1:08 AM, William A Rowe Jr  wrote:
> 
> Let me counter with this... Rather than break the API every m.n release, what 
> if we roll on to 2.6 with no ABI breakage, or resolve with impumity 
> everything wrong in 3.0 with a firm commitment not to break it again till 4.0?

Doesn't that break our understanding/"contract" with all external module 
developers and ISV? Up until now, minor has always indicated ABI changes which 
means, real world, you need to provide a different module build for each minor 
version. Now we would be saying "Nope, not in this case"

That seems, to me, worse than what we have now. Plus, it does nothing to 
satisfy the concerns about "quality" of what is released in any way.

Again, IMO, it's not about numbers, or what we call it, for US. It about QA, 
testing and being more sensitive to regression and wholesale refactoring on 
stuff that is going to be released. Where numbers and versioning DOES matter is 
how it affects distributors and vendors of httpd and the entire module 
eco-system.

Just my 2c

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)])

[Mark Blackman]

> On 20 Apr 2018, at 01:39, Daniel Ruggeri  wrote:
> 
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
> 
> 
> If we end up with API and feature freeze on branch 2.4, then we'd expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
> 
> 
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).

Presumably most/all of that toil can be automated away as you have started 
doing, so that human intervention is only required where human judgement is 
actually required?  Does httpd have some massive CD/CI pipeline in the 
background I don’t see or could it do with one? 

- Mark

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)])

[Ruediger Pluem]

On 04/19/2018 09:19 PM, Rainer Jung wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>
>>
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  wrote:
>>>
>>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
 With all this in mind, should we try to set things up so that the
 next release cycle uses the concept of RCs?

 If so, and if people like, I can come up with a baseline
 proposal on the process for us to debate and come to
 some consensus on.
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
> 
> IMHO we should aim at keeping the RC phase as stable as possible and focuse 
> on the code from which we tagged RC1 and
> which we actually want to release. So after RC1 there should be only fixes 
> for regressions, no other fixes or backports.
> 
> Other projects for example branch at the start of the release process (using 
> your version example 2.4.121 here):
> 
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
>   - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version 
> adjustments
> - do final release vote

+1. Sounds reasonable, gives more time for testing avoids freezes on the 2.4.x 
branch while keeping the RC stable. Let's
try this and see the results.

Regards

Rüdiger

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)])

[William A Rowe Jr]

Let me counter with this... Rather than break the API every m.n release,
what if we roll on to 2.6 with no ABI breakage, or resolve with impumity
everything wrong in 3.0 with a firm commitment not to break it again till
4.0?

This might be the root problem of our trying to !is versioning semantics.


On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri  wrote:

> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).
>
> --
> Daniel Ruggeri
>
> On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> > I don't disagree with RC's entirely, or the mechanism you suggest, but
> > that isn't what I read as proposed.
> >
> > Our issue is that every httpd must be distinguished, we won't ship
> > four tarballs all claiming 2.4.34 (GA). Which one is the person
> > complaining about? Are we back to SHA signature of the source tarball
> > (that isn't even assuredly what they built the binary from?)
> >
> > We can decorate the rc in the versioning, but that isn't part of 2.4.x
> > API, unless we swap out the "-dev" string tag for an "-rc#" value.
> >
> > It is not reasonable to lock a branch for an indeterminate length of
> > time. Branching the RC into what becomes the final release, and making
> > it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> > might help discourage disruptive backports, but there is no suggestion
> > yet of what is acceptable, either on such a frozen main branch or rc
> > branch.
> >
> > In fact our policy reflects that two competing release candidates is
> > an entire valid and even expected situation, and any process that
> > further blocks this should be firmly rebuffed.
> >
> > As it reads so far the proposal is the way we do things, now
> > conserving subversion numbers as precious, if only to reenforce a
> > stake in the ground that version major and minor numbers are similarly
> > precious, (which they are not.)
> >
> > With the addition of freezing changes on 2.4.x branch for a time we
> > succeed in impeading progress towards version .next, while not
> > otherwise changing the status quo.
> >
> > What you suggest is yet another thing, based on forking the RC release
> > branch, and I haven't seen that accepted by the committee yet.
> >
> > On Thu, Apr 19, 2018, 16:43 David Zuelke  > > wrote:
> >
> > The main difference is that you have a release branch in which fixes
> > to bugs or regressions found during 2.4.x RCs can be made, while work
> > on 2.4.(x+1) can continue in the main 2.4 branch.
> >
> > Another benefit is that people who do automated builds (e.g. me) can
> > grep for "RC" in the version number and have it fetch from
> > https://dist.apache.org/repos/dist/dev/httpd/ instead.
> >
> > The changelogs are more readable as well, because it's obvious which
> > intermediary RC releases belong together. If you look at
> > https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> > indication that e.g. 2.4.31 was never released.
> >
> >
> > On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> > > wrote:
> > > What possible improvement occurs if there is no branch discipline
> > > on 2.4.x development? We just echoed effectively your proposal,
> > > using numbers rather than RC designations, and still .33 has this
> > > host of issues. With no release since .29, the branch was in this
> > > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > > .31 didn't result in a better .32, and even the final .33 had
> > its own
> > > issues.
> > >
> > > This would have been precisely the same outcome between RC1
> > > and RC4, if the project doesn't keep the branch stable for even the
> > > week or months required to craft a successful release, and if that
> > > occurs on 2.4.x branch, that is an interruption of effort towards
> > > release n+1, frustrating contributors.
> > >
> > > Note 

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)])

[Daniel Ruggeri]

I'm not sure where in the conversation to add this, but I do want to
point out a mechanical concern.


If we end up with API and feature freeze on branch 2.4, then we'd expect
to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
branch) can't get a feature or the next great thing because of a
required API incompatible change. We would then kick out 2.8, 2.10 and
so on and so forth. This seems like it would satisfy both the
keep-the-stuff-stable as well as the give-users-new-stuff "sides".


Mechanically, this can become tiresome for a volunteer as we work
through the STATUS ceremony for each of the branches. I remember that
being less than enjoyable when 2.0, 2.2 and 2.4 were all release
branches. I'm fearful of a future where we may have five branches and a
bugfix applicable to all (or worse... a security fix that would dictate
all should be released/disclosed at the same time).

-- 
Daniel Ruggeri

On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> I don't disagree with RC's entirely, or the mechanism you suggest, but
> that isn't what I read as proposed.
>
> Our issue is that every httpd must be distinguished, we won't ship
> four tarballs all claiming 2.4.34 (GA). Which one is the person
> complaining about? Are we back to SHA signature of the source tarball
> (that isn't even assuredly what they built the binary from?)
>
> We can decorate the rc in the versioning, but that isn't part of 2.4.x
> API, unless we swap out the "-dev" string tag for an "-rc#" value.
>
> It is not reasonable to lock a branch for an indeterminate length of
> time. Branching the RC into what becomes the final release, and making
> it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> might help discourage disruptive backports, but there is no suggestion
> yet of what is acceptable, either on such a frozen main branch or rc
> branch.
>
> In fact our policy reflects that two competing release candidates is
> an entire valid and even expected situation, and any process that
> further blocks this should be firmly rebuffed.
>
> As it reads so far the proposal is the way we do things, now
> conserving subversion numbers as precious, if only to reenforce a
> stake in the ground that version major and minor numbers are similarly
> precious, (which they are not.)
>
> With the addition of freezing changes on 2.4.x branch for a time we
> succeed in impeading progress towards version .next, while not
> otherwise changing the status quo.
>
> What you suggest is yet another thing, based on forking the RC release
> branch, and I haven't seen that accepted by the committee yet.
>
> On Thu, Apr 19, 2018, 16:43 David Zuelke  > wrote:
>
> The main difference is that you have a release branch in which fixes
> to bugs or regressions found during 2.4.x RCs can be made, while work
> on 2.4.(x+1) can continue in the main 2.4 branch.
>
> Another benefit is that people who do automated builds (e.g. me) can
> grep for "RC" in the version number and have it fetch from
> https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
> The changelogs are more readable as well, because it's obvious which
> intermediary RC releases belong together. If you look at
> https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> indication that e.g. 2.4.31 was never released.
>
>
> On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> > wrote:
> > What possible improvement occurs if there is no branch discipline
> > on 2.4.x development? We just echoed effectively your proposal,
> > using numbers rather than RC designations, and still .33 has this
> > host of issues. With no release since .29, the branch was in this
> > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > .31 didn't result in a better .32, and even the final .33 had
> its own
> > issues.
> >
> > This would have been precisely the same outcome between RC1
> > and RC4, if the project doesn't keep the branch stable for even the
> > week or months required to craft a successful release, and if that
> > occurs on 2.4.x branch, that is an interruption of effort towards
> > release n+1, frustrating contributors.
> >
> > Note we don't publish anything not approved by the PMC, so
> > there would be the same "vote" to release an RC.
> >
> > Net <-> net, this is the status quo which failed us so badly this
> > past winter (now with alphabetic characters!)
> >
> >
> > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  > wrote:
> >> The idea is encouraging and fostering a broader test audience.
> >>
> >>
> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr
> 

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)])

[William A Rowe Jr]

I don't disagree with RC's entirely, or the mechanism you suggest, but that
isn't what I read as proposed.

Our issue is that every httpd must be distinguished, we won't ship four
tarballs all claiming 2.4.34 (GA). Which one is the person complaining
about? Are we back to SHA signature of the source tarball (that isn't even
assuredly what they built the binary from?)

We can decorate the rc in the versioning, but that isn't part of 2.4.x API,
unless we swap out the "-dev" string tag for an "-rc#" value.

It is not reasonable to lock a branch for an indeterminate length of time.
Branching the RC into what becomes the final release, and making it painful
to backport first to 2.4.x and finally 2.4.n-rc branch might help
discourage disruptive backports, but there is no suggestion yet of what is
acceptable, either on such a frozen main branch or rc branch.

In fact our policy reflects that two competing release candidates is an
entire valid and even expected situation, and any process that further
blocks this should be firmly rebuffed.

As it reads so far the proposal is the way we do things, now conserving
subversion numbers as precious, if only to reenforce a stake in the ground
that version major and minor numbers are similarly precious, (which they
are not.)

With the addition of freezing changes on 2.4.x branch for a time we succeed
in impeading progress towards version .next, while not otherwise changing
the status quo.

What you suggest is yet another thing, based on forking the RC release
branch, and I haven't seen that accepted by the committee yet.

On Thu, Apr 19, 2018, 16:43 David Zuelke  wrote:

> The main difference is that you have a release branch in which fixes
> to bugs or regressions found during 2.4.x RCs can be made, while work
> on 2.4.(x+1) can continue in the main 2.4 branch.
>
> Another benefit is that people who do automated builds (e.g. me) can
> grep for "RC" in the version number and have it fetch from
> https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
> The changelogs are more readable as well, because it's obvious which
> intermediary RC releases belong together. If you look at
> https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> indication that e.g. 2.4.31 was never released.
>
>
> On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr 
> wrote:
> > What possible improvement occurs if there is no branch discipline
> > on 2.4.x development? We just echoed effectively your proposal,
> > using numbers rather than RC designations, and still .33 has this
> > host of issues. With no release since .29, the branch was in this
> > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > .31 didn't result in a better .32, and even the final .33 had its own
> > issues.
> >
> > This would have been precisely the same outcome between RC1
> > and RC4, if the project doesn't keep the branch stable for even the
> > week or months required to craft a successful release, and if that
> > occurs on 2.4.x branch, that is an interruption of effort towards
> > release n+1, frustrating contributors.
> >
> > Note we don't publish anything not approved by the PMC, so
> > there would be the same "vote" to release an RC.
> >
> > Net <-> net, this is the status quo which failed us so badly this
> > past winter (now with alphabetic characters!)
> >
> >
> > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
> >> The idea is encouraging and fostering a broader test audience.
> >>
> >>
> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr 
> wrote:
> >>
> >> Unless I misunderstand...
> >>
> >> 2.4.30-RC1 (rejected)
> >> 2.4.30-RC2 (our .31, rejected)
> >> 2.4.30-RC3 (our .32, rejected)
> >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> >>
> >> With all the associated changes in between, no actual change in branch
> >> management, scope, feature creep, etc?
> >>
> >> This sounds like dressing up the status quo with different labels.
> >>
> >>
> >>
> >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
> >>>
> >>>
> >>>
> >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  >
> >>> > wrote:
> >>> >
> >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski 
> wrote:
> >>> >> With all this in mind, should we try to set things up so that the
> >>> >> next release cycle uses the concept of RCs?
> >>> >>
> >>> >> If so, and if people like, I can come up with a baseline
> >>> >> proposal on the process for us to debate and come to
> >>> >> some consensus on.
> >>> >
> >>> > Would you define an RC? What changes are allowable in that branch?
> >>>
> >>>
> >>> The idea is that right now we take an existing state in SVN
> >>> and tag it as, for example, 2.4.121. We then vote on that tag
> >>> and the artifacts released from that tag. No work is done on
> >>> the 2.4 branch 

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)])

[David Zuelke]

The main difference is that you have a release branch in which fixes
to bugs or regressions found during 2.4.x RCs can be made, while work
on 2.4.(x+1) can continue in the main 2.4 branch.

Another benefit is that people who do automated builds (e.g. me) can
grep for "RC" in the version number and have it fetch from
https://dist.apache.org/repos/dist/dev/httpd/ instead.

The changelogs are more readable as well, because it's obvious which
intermediary RC releases belong together. If you look at
https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
indication that e.g. 2.4.31 was never released.


On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr  wrote:
> What possible improvement occurs if there is no branch discipline
> on 2.4.x development? We just echoed effectively your proposal,
> using numbers rather than RC designations, and still .33 has this
> host of issues. With no release since .29, the branch was in this
> continuous state of flux between 2.4.30 and 2.4.33. Testing the
> 2.4.30 release did not result in a better, eventual 2.4.31, testing
> .31 didn't result in a better .32, and even the final .33 had its own
> issues.
>
> This would have been precisely the same outcome between RC1
> and RC4, if the project doesn't keep the branch stable for even the
> week or months required to craft a successful release, and if that
> occurs on 2.4.x branch, that is an interruption of effort towards
> release n+1, frustrating contributors.
>
> Note we don't publish anything not approved by the PMC, so
> there would be the same "vote" to release an RC.
>
> Net <-> net, this is the status quo which failed us so badly this
> past winter (now with alphabetic characters!)
>
>
> On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
>> The idea is encouraging and fostering a broader test audience.
>>
>>
>> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
>>
>> Unless I misunderstand...
>>
>> 2.4.30-RC1 (rejected)
>> 2.4.30-RC2 (our .31, rejected)
>> 2.4.30-RC3 (our .32, rejected)
>> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>>
>> With all the associated changes in between, no actual change in branch
>> management, scope, feature creep, etc?
>>
>> This sounds like dressing up the status quo with different labels.
>>
>>
>>
>> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
>>>
>>>
>>>
>>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>>> > wrote:
>>> >
>>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>>> >> With all this in mind, should we try to set things up so that the
>>> >> next release cycle uses the concept of RCs?
>>> >>
>>> >> If so, and if people like, I can come up with a baseline
>>> >> proposal on the process for us to debate and come to
>>> >> some consensus on.
>>> >
>>> > Would you define an RC? What changes are allowable in that branch?
>>>
>>>
>>> The idea is that right now we take an existing state in SVN
>>> and tag it as, for example, 2.4.121. We then vote on that tag
>>> and the artifacts released from that tag. No work is done on
>>> the 2.4 branch while testing is done so that we ensure that
>>> the SVN rev on branch == the one for the tag
>>
>>
>> Not necessary to freeze; a tag can always be applied to an older rev.
>>
>>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>>> vote does not pass, we continue on the 2.4 branch, fix the
>>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>>
>>> If the vote does pass we tag the branch, which is still == RC#
>>> at this stage, as 2.4.121 (ap_release.h mods included). We
>>> still even at this stage test and vote on the release as we have
>>> for decades. If it passes, we release. If not, for some reason,
>>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>>> the above.
>>>
>>> This is the overall idea... more flesh to be added.
>>
>>

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)])

[William A Rowe Jr]

What possible improvement occurs if there is no branch discipline
on 2.4.x development? We just echoed effectively your proposal,
using numbers rather than RC designations, and still .33 has this
host of issues. With no release since .29, the branch was in this
continuous state of flux between 2.4.30 and 2.4.33. Testing the
2.4.30 release did not result in a better, eventual 2.4.31, testing
.31 didn't result in a better .32, and even the final .33 had its own
issues.

This would have been precisely the same outcome between RC1
and RC4, if the project doesn't keep the branch stable for even the
week or months required to craft a successful release, and if that
occurs on 2.4.x branch, that is an interruption of effort towards
release n+1, frustrating contributors.

Note we don't publish anything not approved by the PMC, so
there would be the same "vote" to release an RC.

Net <-> net, this is the status quo which failed us so badly this
past winter (now with alphabetic characters!)


On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
> The idea is encouraging and fostering a broader test audience.
>
>
> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
>
> Unless I misunderstand...
>
> 2.4.30-RC1 (rejected)
> 2.4.30-RC2 (our .31, rejected)
> 2.4.30-RC3 (our .32, rejected)
> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>
> With all the associated changes in between, no actual change in branch
> management, scope, feature creep, etc?
>
> This sounds like dressing up the status quo with different labels.
>
>
>
> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
>>
>>
>>
>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>> > wrote:
>> >
>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>> >> With all this in mind, should we try to set things up so that the
>> >> next release cycle uses the concept of RCs?
>> >>
>> >> If so, and if people like, I can come up with a baseline
>> >> proposal on the process for us to debate and come to
>> >> some consensus on.
>> >
>> > Would you define an RC? What changes are allowable in that branch?
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag
>
>
> Not necessary to freeze; a tag can always be applied to an older rev.
>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>

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)])

[David Zuelke]

Yup, that's exactly it. Have a release branch, iterate there, and in
the meantime, work in the version series branch can continue. That
brings one huge benefit over the current model already: no freezes
necessary, no potential additional breaks after a "burned" version.

On Thu, Apr 19, 2018 at 9:19 PM, Rainer Jung  wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>
>>
>>
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>>> wrote:
>>>
>>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:

 With all this in mind, should we try to set things up so that the
 next release cycle uses the concept of RCs?

 If so, and if people like, I can come up with a baseline
 proposal on the process for us to debate and come to
 some consensus on.
>>>
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>
> IMHO we should aim at keeping the RC phase as stable as possible and focuse
> on the code from which we tagged RC1 and which we actually want to release.
> So after RC1 there should be only fixes for regressions, no other fixes or
> backports.
>
> Other projects for example branch at the start of the release process (using
> your version example 2.4.121 here):
>
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
>   - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version
> adjustments
> - do final release vote
>
> While we are doing RCs backport and other fixing work could proceed on the
> 2.4.x branch, because the RCs are created from the version branch.
>
> ... 2c ...
>
> Rainer

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)])

[Rainer Jung]

Am 19.04.2018 um 17:37 schrieb Jim Jagielski:




On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  wrote:

On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:

With all this in mind, should we try to set things up so that the
next release cycle uses the concept of RCs?

If so, and if people like, I can come up with a baseline
proposal on the process for us to debate and come to
some consensus on.


Would you define an RC? What changes are allowable in that branch?



The idea is that right now we take an existing state in SVN
and tag it as, for example, 2.4.121. We then vote on that tag
and the artifacts released from that tag. No work is done on
the 2.4 branch while testing is done so that we ensure that
the SVN rev on branch == the one for the tag.

Instead, we tag at 2.4.121-RC1. We do the exact same. If the
vote does not pass, we continue on the 2.4 branch, fix the
issues, and then tag a 2.4.121-RC2. Rinse and repeat.

If the vote does pass we tag the branch, which is still == RC#
at this stage, as 2.4.121 (ap_release.h mods included). We
still even at this stage test and vote on the release as we have
for decades. If it passes, we release. If not, for some reason,
we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
the above.

This is the overall idea... more flesh to be added.


IMHO we should aim at keeping the RC phase as stable as possible and 
focuse on the code from which we tagged RC1 and which we actually want 
to release. So after RC1 there should be only fixes for regressions, no 
other fixes or backports.


Other projects for example branch at the start of the release process 
(using your version example 2.4.121 here):


- branch 2.4.x as a 2.4.121 branch
- tag 2.4.121-RC1 on that branch
- allow for a week or two (?) of public testing
- fix incoming regressions
  - patches go via trunk to 2.4.x to 2.4.121 branch
- cut new RCs if previous RC needed fixes
- create final release tag from last RC plus some script driven version 
adjustments

- do final release vote

While we are doing RCs backport and other fixing work could proceed on 
the 2.4.x branch, because the RCs are created from the version branch.


... 2c ...

Rainer

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)])

[Jim Jagielski]

The idea is encouraging and fostering a broader test audience.

> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
> 
> Unless I misunderstand...
> 
> 2.4.30-RC1 (rejected)
> 2.4.30-RC2 (our .31, rejected)
> 2.4.30-RC3 (our .32, rejected)
> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> 
> With all the associated changes in between, no actual change in branch 
> management, scope, feature creep, etc?
> 
> This sounds like dressing up the status quo with different labels.
> 
> 
> 
> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  > wrote:
> 
> 
> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  > > wrote:
> > 
> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  > > wrote:
> >> With all this in mind, should we try to set things up so that the
> >> next release cycle uses the concept of RCs?
> >> 
> >> If so, and if people like, I can come up with a baseline
> >> proposal on the process for us to debate and come to
> >> some consensus on.
> > 
> > Would you define an RC? What changes are allowable in that branch?
> 
> 
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag
> 
> Not necessary to freeze; a tag can always be applied to an older rev.
> 
> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
> 
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
> 
> This is the overall idea... more flesh to be added.

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)])

[William A Rowe Jr]

Unless I misunderstand...

2.4.30-RC1 (rejected)
2.4.30-RC2 (our .31, rejected)
2.4.30-RC3 (our .32, rejected)
2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)

With all the associated changes in between, no actual change in branch
management, scope, feature creep, etc?

This sounds like dressing up the status quo with different labels.



On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:

>
>
> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
> wrote:
> >
> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
> >> With all this in mind, should we try to set things up so that the
> >> next release cycle uses the concept of RCs?
> >>
> >> If so, and if people like, I can come up with a baseline
> >> proposal on the process for us to debate and come to
> >> some consensus on.
> >
> > Would you define an RC? What changes are allowable in that branch?
>
>
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag
>

Not necessary to freeze; a tag can always be applied to an older rev.

Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
>
> This is the overall idea... more flesh to be added.

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)])

[Jim Jagielski]

> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  wrote:
> 
> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>> With all this in mind, should we try to set things up so that the
>> next release cycle uses the concept of RCs?
>> 
>> If so, and if people like, I can come up with a baseline
>> proposal on the process for us to debate and come to
>> some consensus on.
> 
> Would you define an RC? What changes are allowable in that branch?


The idea is that right now we take an existing state in SVN
and tag it as, for example, 2.4.121. We then vote on that tag
and the artifacts released from that tag. No work is done on
the 2.4 branch while testing is done so that we ensure that
the SVN rev on branch == the one for the tag.

Instead, we tag at 2.4.121-RC1. We do the exact same. If the
vote does not pass, we continue on the 2.4 branch, fix the
issues, and then tag a 2.4.121-RC2. Rinse and repeat.

If the vote does pass we tag the branch, which is still == RC#
at this stage, as 2.4.121 (ap_release.h mods included). We
still even at this stage test and vote on the release as we have
for decades. If it passes, we release. If not, for some reason,
we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
the above.

This is the overall idea... more flesh to be added.

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)])

[William A Rowe Jr]

On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
> With all this in mind, should we try to set things up so that the
> next release cycle uses the concept of RCs?
>
> If so, and if people like, I can come up with a baseline
> proposal on the process for us to debate and come to
> some consensus on.

Would you define an RC? What changes are allowable in that branch?

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)])

[Jim Jagielski]

With all this in mind, should we try to set things up so that the
next release cycle uses the concept of RCs?

If so, and if people like, I can come up with a baseline
proposal on the process for us to debate and come to
some consensus on.