Re: A proposal...

>> One thing you mention above is "wait for a new minor release". I can >> definitely see that being an issue for our current maj.minor layout given >> that minor bumps are measured in years. In this proposal, unless there's a >> pressing need to send out a patch release right now, the next

Re: A proposal...

Am 24.04.2018 um 19:58 schrieb Daniel Ruggeri: On 2018-04-24 09:22, Eric Covener wrote: On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr wrote: On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: Yes, exactly correct. We have three "contracts" to

Re: A proposal...

At the pace of our (currently 'minor', contrast to 'patch') releases there are about 2-4 / year. I agree with the idea of monthly bug fix patch releases. Declaring the first minor of each year as LTS for 2 years, we could get security fixes into legacy users hands. It would be a good starting

Re: A proposal...

> Should we also need some kind of LTS version? If yes, how to choose them? I think it would be required with frequent minor releases.

Re: A proposal...

Le 24/04/2018 à 19:58, Daniel Ruggeri a écrit : One thing you mention above is "wait for a new minor release". I can definitely see that being an issue for our current maj.minor layout given that minor bumps are measured in years. In this proposal, unless there's a pressing need to send out a

Re: A proposal...

On 2018-04-24 09:22, Eric Covener wrote: On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr wrote: On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: Yes, exactly correct. We have three "contracts" to keep that I think aligns very well with the

Re: A proposal...

On Tue, Apr 24, 2018 at 4:22 PM, Eric Covener wrote: > On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr > wrote: >> On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: Yes, exactly correct. We have three "contracts" to keep

Re: A proposal...

As express by others, please don't ! IMHO, ONE language/framework is all what we need. Having a set of unrelated materials will bring nightmares and something hard, not to say impossible, to maintain/understand. So we should keep it as-is, or switch to something new. But trying to please

Re: AW: A proposal...

> I would say that leaves us with Perl, Python or > something like that as base language. The reasons I suggested Lua previously is because it's the only programming language modules found in the sources of httpd: https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ specifically:

Re: A proposal...

On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr wrote: > On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: >>> Yes, exactly correct. We have three "contracts" to keep that I think aligns >>> very well with the following semver "contracts": >>>

Re: A proposal...

On Tue, Apr 24, 2018 at 8:37 AM, Plüm, Rüdiger, Vodafone Group wrote: > > If we switch the framework we need to consider that with all gaps we have, we > already have > a large amount of tests in the current framework that need to be ported over > time. The OpenSSL

Re: A proposal...

On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: >> Yes, exactly correct. We have three "contracts" to keep that I think aligns >> very well with the following semver "contracts": >> Major => API/ABI compatibility for modules >> Minor => Feature and directives >> 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 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).

AW: A proposal...

> -Ursprüngliche Nachricht- > Von: Eric Covener > Gesendet: Dienstag, 24. April 2018 15:31 > An: Apache HTTP Server Development List > Betreff: Re: A proposal... > > On Tue, Apr 24, 2018 at 8:50 AM, Jim Jagielski wrote: > >

Re: A proposal...

On Tue, Apr 24, 2018 at 8:50 AM, Jim Jagielski wrote: > One idea is that we setup, using the existing perl test framework, a sort of > "catch all" test, where the framework simply runs all scripts from a subdir > via system() (or whatever), and the reports success or failure.

Re: A proposal...

> Yes, exactly correct. We have three "contracts" to keep that I think aligns > very well with the following semver "contracts": > Major => API/ABI compatibility for modules > Minor => Feature and directives > Patch => Functional and configuration syntax guarantees > > Demonstrating by way of a

Re: A proposal...

On 04/24/2018 02:52 PM, Daniel Ruggeri wrote: > > In all cases, the changelog would clearly state the changes and we would ship > what we consider to be the best default config. Ideally, we would also point > the changelog entry to the SVN patches which implement the change so > downstream

Re: A proposal...

Hi, Jim; Further to that point, simply reaping the exit code of zero or non-zero should be enough for a test to communicate success or failure. My only concern with this concept is that it could make our testing framework require a *very* unique set of system libraries, binaries and

Re: A proposal...

On April 24, 2018 6:53:52 AM CDT, Ruediger Pluem wrote: > > >On 04/24/2018 01:19 PM, Daniel Ruggeri wrote: >> >> >> On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" > wrote: >>> >>> -Ursprüngliche Nachricht-

Re: A proposal...

One idea is that we setup, using the existing perl test framework, a sort of "catch all" test, where the framework simply runs all scripts from a subdir via system() (or whatever), and the reports success or failure. Those scripts could be written in anything. This would mean that people could

Re: A proposal...

On 04/24/2018 01:50 PM, Rainer Jung wrote: > Am 24.04.2018 um 13:19 schrieb Daniel Ruggeri: >> >> >> On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" >> wrote: >>> >>> -Ursprüngliche Nachricht- Von: Rainer Jung

Re: A proposal...

On 04/24/2018 01:19 PM, Daniel Ruggeri wrote: > > > On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" > wrote: >> >> >>> -Ursprüngliche Nachricht- >>> Von: Rainer Jung >>> Gesendet: Montag, 23. April 2018 16:47

Re: A proposal...

Am 24.04.2018 um 13:19 schrieb Daniel Ruggeri: On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" wrote: -Ursprüngliche Nachricht- Von: Rainer Jung Gesendet: Montag, 23. April 2018 16:47 An:

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: A proposal...

On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" wrote: > > >> -Ursprüngliche Nachricht- >> Von: Rainer Jung >> Gesendet: Montag, 23. April 2018 16:47 >> An: dev@httpd.apache.org >> Betreff: Re: A proposal... >>

Re: Start using RCs

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

Re: Expanding httpd adoption internationally - POC

Am 24.04.2018 um 07:20 schrieb Marion et Christophe JAILLET: Le 24/04/2018 à 02:58, William A Rowe Jr a écrit : On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET wrote: Le 18/04/2018 à 22:12, William A Rowe Jr a écrit : On Wed, Apr 18, 2018 at 2:31

AW: A proposal...

> -Ursprüngliche Nachricht- > Von: Rainer Jung > Gesendet: Montag, 23. April 2018 16:47 > An: dev@httpd.apache.org > Betreff: Re: A proposal... > > Am 23.04.2018 um 16:00 schrieb Jim Jagielski: > > It seems that, IMO, if there was not so much concern about >

AW: A proposal...

> -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Montag, 23. April 2018 17:08 > An: dev@httpd.apache.org > Betreff: Re: A proposal... > > Such undocumented and untested behaviour, which nevertheless is > considered a regression, cannot be