>> 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
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
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
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
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
> 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.
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
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
> -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
> -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
>
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
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
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
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
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
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
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:
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...
>>
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-
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
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.
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).
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
> 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
> -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:
> >
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
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":
>>>
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 =>
> 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:
29 matches
Mail list logo