>> 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 version
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 keep that I
think aligns very well with t
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 poin
> 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.
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
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 following semver "contracts":
Major => API/A
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 that I think
aligns very well with the following semver
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 eve
> 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: https://
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":
>>> Major => API/ABI compatibility for modules
>>
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 project overhauled their test
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 => Functional and confi
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
> "lo
> -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:
> > One idea is that we setup, using the existing perl test frame
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. Those scripts
> co
> 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 fe
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 h
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
inter
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-
Von: Rainer Jung
Gesendet: Montag, 23. April
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 a
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
Gesendet: Montag, 23. April 2018 16:47
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
>>> An: dev@httpd.apache.org
>>> Betreff: 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: dev@httpd.apache.org
Betreff: Re: A proposal...
Am 23.04.2018 um 16:00 sc
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
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...
>>
>> Am 23.04.2018 um 16:00 schrieb Jim Jagielski:
>> > It
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...
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 PM, Nick Kew wrote:
I suspect
27 matches
Mail list logo