Re: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Jim Jagielski]

> On Oct 25, 2017, at 7:48 AM, Eric Covener  wrote:
> 
>> The guidelines are fine with me and seem to make sense to get to an API
>> stable next GA. It is good to have a list of 'To Do's' that needs to be done
>> before next GA. That helps people looking for interesting and useful work to 
>> spend their time :-).
>> Once it is decided that the API is stable I guess we need
>> to branch in order to avoid restraining further progress on trunk by 
>> developers
>> that want to change the API further in an incompatible way. This could still 
>> be a '2.5.x' branch
>> that morphs into a 2.6.x or 3.0.x branch later.
>> 
>> My personal itch and use of my regrettably very limited amount of time these 
>> days is
>> on the current 2.4 and getting at least some of the features back into it
>> (a little bit like Jim's approach). This has to do with my dayjob where it 
>> is much easier
>> to upgrade to 2.4.next than to a new GA version.
>> But I see merit in getting more track on moving forward with current trunk 
>> to something
>> releasable. So go for the alpha tags and see if you get sufficient votes for 
>> it and what
>> the feedback of the broader community is. If it is valuable: Great. If not
>> or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
>> just stop
>> due to lack of interest in the community.
> 
> +1

Same here. +1!

Re: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Eric Covener]

> The guidelines are fine with me and seem to make sense to get to an API
> stable next GA. It is good to have a list of 'To Do's' that needs to be done
> before next GA. That helps people looking for interesting and useful work to 
> spend their time :-).
> Once it is decided that the API is stable I guess we need
> to branch in order to avoid restraining further progress on trunk by 
> developers
> that want to change the API further in an incompatible way. This could still 
> be a '2.5.x' branch
> that morphs into a 2.6.x or 3.0.x branch later.
>
> My personal itch and use of my regrettably very limited amount of time these 
> days is
> on the current 2.4 and getting at least some of the features back into it
> (a little bit like Jim's approach). This has to do with my dayjob where it is 
> much easier
> to upgrade to 2.4.next than to a new GA version.
> But I see merit in getting more track on moving forward with current trunk to 
> something
> releasable. So go for the alpha tags and see if you get sufficient votes for 
> it and what
> the feedback of the broader community is. If it is valuable: Great. If not
> or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
> just stop
> due to lack of interest in the community.

+1

AW: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Dienstag, 24. Oktober 2017 19:00
> An: httpd <dev@httpd.apache.org>
> Betreff: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines
> 
> I'd like to propose the following, so we can decide on what course to
> chart between here and there.
> 
> Today we are at 2.5.0-dev, slated to become 2.5.0 non-GA release.
> Through a series of non-GA releases, 2.5.x is eventually approved to
> become the next 'evens' GA release. What we number that by default is
> 2.6.0, or if the group decides the changes are significant enough,
> 3.0.0.
> 
> What I propose now is that we designate all 2.5.x releases as -alpha
> *until the list decides the API (not ABI) changes are complete*.
> That's the only process change.
> 
> We track this through STATUS, with a vote to promote API-changing
> proposals to SHOWSTOPPERs to -beta. So developers will be aware when
> we declare -beta that we will no longer change the API for them, and
> their modules must conform to the new API, barring any radical
> discoveries that prevent us from shipping that API (which might then
> return us to the -alpha phase.)
> 
> E.g. we had a security@ discussion about changing the handling of URI
> significantly so that the meaning of escaped vs. unescaped characters
> is never obtuse. There are several proposals on that table (embargoed
> at that time waiting for our HTTP protocol correctness patches to be
> published.) Those need to come here to dev@. One of them will land in
> STATUS, and will inevitably be upvoted to SHOWSTOPPER status;
> 2.5.x-beta shouldn't happen, IMO, until some code and structure
> changes to accomplish this has been accepted.
> 
> Because it is CTR, we don't need STATUS for patch voting, but I do
> think we want STATUS to identify what is the minimum changes needed to
> declare the next API/ABI-breaking release complete and ready for
> -beta.
> 
> Thoughts?

The guidelines are fine with me and seem to make sense to get to an API
stable next GA. It is good to have a list of 'To Do's' that needs to be done
before next GA. That helps people looking for interesting and useful work to 
spend their time :-).
Once it is decided that the API is stable I guess we need
to branch in order to avoid restraining further progress on trunk by developers
that want to change the API further in an incompatible way. This could still be 
a '2.5.x' branch
that morphs into a 2.6.x or 3.0.x branch later.

My personal itch and use of my regrettably very limited amount of time these 
days is
on the current 2.4 and getting at least some of the features back into it
(a little bit like Jim's approach). This has to do with my dayjob where it is 
much easier
to upgrade to 2.4.next than to a new GA version.
But I see merit in getting more track on moving forward with current trunk to 
something
releasable. So go for the alpha tags and see if you get sufficient votes for it 
and what
the feedback of the broader community is. If it is valuable: Great. If not
or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
just stop
due to lack of interest in the community.


Regards

Rüdiger

[Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[William A Rowe Jr]

I'd like to propose the following, so we can decide on what course to
chart between here and there.

Today we are at 2.5.0-dev, slated to become 2.5.0 non-GA release.
Through a series of non-GA releases, 2.5.x is eventually approved to
become the next 'evens' GA release. What we number that by default is
2.6.0, or if the group decides the changes are significant enough,
3.0.0.

What I propose now is that we designate all 2.5.x releases as -alpha
*until the list decides the API (not ABI) changes are complete*.
That's the only process change.

We track this through STATUS, with a vote to promote API-changing
proposals to SHOWSTOPPERs to -beta. So developers will be aware when
we declare -beta that we will no longer change the API for them, and
their modules must conform to the new API, barring any radical
discoveries that prevent us from shipping that API (which might then
return us to the -alpha phase.)

E.g. we had a security@ discussion about changing the handling of URI
significantly so that the meaning of escaped vs. unescaped characters
is never obtuse. There are several proposals on that table (embargoed
at that time waiting for our HTTP protocol correctness patches to be
published.) Those need to come here to dev@. One of them will land in
STATUS, and will inevitably be upvoted to SHOWSTOPPER status;
2.5.x-beta shouldn't happen, IMO, until some code and structure
changes to accomplish this has been accepted.

Because it is CTR, we don't need STATUS for patch voting, but I do
think we want STATUS to identify what is the minimum changes needed to
declare the next API/ABI-breaking release complete and ready for
-beta.

Thoughts?