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: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

Am 20.04.2018 um 11:39 schrieb Eric Covener: On Fri, Apr 20, 2018 at 3:15 AM, Rainer Jung wrote: Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: *) poll, port: re-add the wakeup pipe to the pollset after it triggered. Not doing this occasionally

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: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On Fri, Apr 20, 2018 at 3:15 AM, Rainer Jung wrote: > Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: > > *) poll, port: re-add the wakeup pipe to the pollset after it triggered. >Not doing this occasionally lead to httpd event MPM processes hanging >

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

On Fri, Apr 20, 2018 at 2:36 AM, Rainer Jung wrote: > >> The necessity/evaluation of the dependency belongs >> here... we once could compile httpd 2.4 against APR 1.4 family and had >> agreement that this would continue through the lifecycle, but I seriously >> doubt that

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: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

Am 20.04.2018 um 09:22 schrieb William A Rowe Jr: On Fri, Apr 20, 2018 at 2:15 AM, Rainer Jung wrote: Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: *) poll, port: re-add the wakeup pipe to the pollset after it triggered. Not doing this

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

On Fri, Apr 20, 2018 at 2:15 AM, Rainer Jung wrote: > Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: > > *) poll, port: re-add the wakeup pipe to the pollset after it triggered. >Not doing this occasionally lead to httpd event MPM processes hanging >

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

Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES: *) poll, port: re-add the wakeup pipe to the pollset after it triggered. Not doing this occasionally lead to httpd event MPM processes hanging during process shutdown. PR 61786. [Yann Ylavic] From the commit log:

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: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

I don't think Stefan is proposing that we mindlessly ship based on an arbitrary set of dates. That'd be too corporate :-) I think in the past you mentioned that we have had features/fixes/Good Stuff(tm) that was probably *ready*... just not yet released. I do recall a few times where there

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: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

On 4/19/2018 7:55 AM, Eric Covener wrote: >> Again, this would be your burden and call until we have so much >> routine/automation that everyone can do it. So it needs to be your decision. > No offense intended here, but I did not really see as many html / > script / process updates as I had

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

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:08 AM, Jim Jagielski wrote: > >> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr wrote: >> >> and BFDL/NIH-tier levels of "we don't do that, we do things this way... my >> way or the highway." > > That is not quite true nor

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

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.

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 10:47 AM, William A Rowe Jr wrote: > > and BFDL/NIH-tier levels of "we don't do that, we do things this way... my > way or the highway." > That is not quite true nor fair. It does not take a BFDL/NIH-er, for example, to say "We don't release s/w

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, 09:32 Jim Jagielski wrote: > > > > On Apr 19, 2018, at 10:20 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > > > > Frankly, I think the current state of things does not work well. It > seems folly to say we should change nothing, only have

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 10:20 AM, Stefan Eissing > wrote: > > Frankly, I think the current state of things does not work well. It seems > folly to say we should change nothing, only have more stable releases. No one is saying we change *nothing*. There just seems

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

i <j...@jagunet.com> >> Gesendet: Donnerstag, 19. April 2018 15:06 >> An: dev@httpd.apache.org >> Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit >> Versioning? (Was: 2.4.3x regression w/SSL vhost configs)] >> >> One of the great thi

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

2018-04-19 15:40 GMT+02:00 Eric Covener : > On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski wrote: > > I agree a case could be made for considering adding an RC stage > > to our release process... it would require some additional tooling > > and some sort of

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

l 2018 15:06 > An: dev@httpd.apache.org > Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit > Versioning? (Was: 2.4.3x regression w/SSL vhost configs)] > > One of the great things about working on open source is that > one is NOT burdened by schedules. That relea

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 9:31 AM, Jim Jagielski wrote: > I agree a case could be made for considering adding an RC stage > to our release process... it would require some additional tooling > and some sort of additions to ap_release.h but nothing insurmountable. > > That might be

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

I agree a case could be made for considering adding an RC stage to our release process... it would require some additional tooling and some sort of additions to ap_release.h but nothing insurmountable. That might be a nice small-and-easily-reversable step to address some of the issues that we've

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

++1 The current versioning and times are fine for me. Only the vote time is too short. At Apachelounge I have once in a while RC’s from branches before voting, so the community had more time to test. Issues are then earlier discovered. Distributors are free to have a RC any time when they

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

One of the great things about working on open source is that one is NOT burdened by schedules. That releases are done "when ready" not when some artificial schedule or some calendar date demands. Changing this mindset on httpd would be an extremely major change, IMO, from what's been at its heart

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

> Again, this would be your burden and call until we have so much > routine/automation that everyone can do it. So it needs to be your decision. No offense intended here, but I did not really see as many html / script / process updates as I had expected. I was hoping the new eyes would get some

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

On Wed, Apr 18, 2018 at 6:43 PM, Daniel Ruggeri wrote: > On 4/18/2018 10:58 AM, William A Rowe Jr wrote: >>> The release cycle is hours, to the benefit of all interested. Be it a >>> blocking bug fixed or a nice feature implemented. These are mostly people >>> who do it

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

Daniel, would you find it feasible to make a 2.4 release every first Tuesday of the month? Other projects have excellent experiences with such release timings. I‘d expect this would let us focus on the changes („one more week until release“), take off pressure („we can do it in the next

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

On 4/18/2018 10:58 AM, William A Rowe Jr wrote: >> The release cycle is hours, to the benefit of all interested. Be it a >> blocking bug fixed or a nice feature implemented. These are mostly people >> who do it for fun. Some even run large server clusters, so a „hobbyist“ >> label does not