Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On 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).

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On 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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On Sun, Apr 22, 2018 at 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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On 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

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

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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On Sun, Apr 22, 2018 at 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

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

> 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

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

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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

> On 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

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

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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

> On 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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

> On 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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

> On 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

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On 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