Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <CACsi25017+0G9T_hREsHwfBiPLaYBYvM-he+rZa2ZGMNt9TXLA@mail.gmail.com>
References: <04A93E80-1065-4B4E-9239-64598930A6E2@jaguNET.com>
 <CACsi2515OJ=BQ8JP1jrg9Unt5PAa0KsVK9xWcWGswH0BqWeM6g@mail.gmail.com>
 <B9F54973-4F03-4300-8EBA-ED397BC1D35B@jaguNET.com> <23725bbe-c891-9a17-cb19-b89920670909@rcbowen.com>
 <7887B89B-0BA2-4874-927E-ADC6A04F3B13@jaguNET.com> <CACsi25017+0G9T_hREsHwfBiPLaYBYvM-he+rZa2ZGMNt9TXLA@mail.gmail.com>
From: Yann Ylavic <ylavic.dev@gmail.com>
Date: Thu, 29 Dec 2016 01:42:34 +0100
Message-ID: <CAKQ1sVNMq7AL0dqn5k6CqDnxnwOpV==-bTkKL2iXMCgiJV0DWw@mail.gmail.com>
Subject: Re: Post 2.4.25
To: httpd-dev <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Thu, 29 Dec 2016 00:42:45 -0000

[Bill, you definitely should do something with your email client, e.g.
using plain text only, replying to your messages breaks indentation
level (like the number of '>' preceding/according to the initial
message)].

On Thu, Dec 29, 2016 at 12:28 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>
> On Dec 24, 2016 07:57, "Jim Jagielski" <jim@jagunet.com> wrote:
>
[For example, here I had to add a '>' for Jim's original text to be
associated with the above "Jim ... wrote:"]
>>
>> My point is that even having a 6 month minimal (and that
>> is, IMO, widely optimistic and unrealistic) of "no new
>> features for 2.4" means that we are basically giving people
>> reasons to drop httpd. It would be a widely different story
>> if (1) trunk was ready to release and (2) we "committed" to
>> releasing trunk quickly by focusing on low-hanging fruit
>> which would make lives happier and better for our end-users.
>> As I said, my fear is that we will not be able to "control"
>> ourselves in limiting what is in 2.6, which will push the
>> actual release far past the point where it is even relevant.
>
> Well as breaking changes go, changing URI to remain an encoded value and to
> mandate module authors accept that req_rec is free threaded are breaking
> changes.

Not sure what the second point means, but preserving r->uri while also
allowing to (and internally work with) an escaped form of the URI does
not necessarily require an API change.
(We could possibly have an opaque struct to manipulate the URI in its
different forms and some helper(s) be compatible with the API changes'
requirements, e.g. 2.4.x).

Regarding the changes in configuration/behaviours, I don't think we
should break things anyway (even accross majors, if possible/relevant
of course), but rather provide options to have the one or the other
behaviour (trunk having the now considered better behaviour, stable(s)
the compatible one).

My point is mainly that rather than focusing on version numbers, we
probably should focus on:
1. what we have now (in trunk), and want to backport
2. what we don't have now, do it (the better wrt trunk), and go to 1.

There's (almost) always a way to backport things, though it should not
prevent us from doing the *necessary* changes (in trunk) for new
improvements/features.

Yet, first step is the "inventory" of what we have/want, each/all of
us involved and constructive...

Once this is done, let's see what is compatible or not (and if yes at
which cost).
If we are going to introduce incompatible features, let's do 3.x.
If we are going to introduce many features at once, let's do 2.6.x
(that's an announce/marketing "value", the user does not care about
the version, (s)he does about the features).
Otherwise let's continue improving trunk with 2.4.x.

When we start implementing new features, first discuss/specify them,
then implement, and see if it's compatible/backportable.
For now, I don't see many (if any) incompatibilities in trunk (I
surely don't have an exhaustive view), but many improvements to
backport.

Just my 2 cts...

Regards,
Yann.