Trunk, 2.5/2.6 and 2.4 back ports (Re: svn commit: r1826862 - /httpd/httpd/branches/2.4.x/STATUS)

[Jim Jagielski <ji...@jaguNET.com>]

> On Mar 15, 2018, at 4:39 PM, ylavic@apache.org wrote:
> 
> Author: ylavic
> Date: Thu Mar 15 20:39:42 2018
> New Revision: 1826862
> 
> URL: http://svn.apache.org/viewvc?rev=1826862&view=rev
> Log:
> Makes sense, withdrawing.
> 
> Modified:
>    httpd/httpd/branches/2.4.x/STATUS
> 

When we run into things like this, what should our policy by? Should we
also remove the code from trunk? From a 2.6/2.5 branch? Or do we
leave code and functionality in that causes "concern" related to it
being a back port, depending, of course, on what that concern *is*.

Re: Trunk, 2.5/2.6 and 2.4 back ports (Re: svn commit: r1826862 - /httpd/httpd/branches/2.4.x/STATUS)

[Eric Covener <co...@gmail.com>]

On Fri, Mar 16, 2018 at 9:01 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>
>> On Mar 15, 2018, at 4:39 PM, ylavic@apache.org wrote:
>>
>> Author: ylavic
>> Date: Thu Mar 15 20:39:42 2018
>> New Revision: 1826862
>>
>> URL: http://svn.apache.org/viewvc?rev=1826862&view=rev
>> Log:
>> Makes sense, withdrawing.
>>
>> Modified:
>>    httpd/httpd/branches/2.4.x/STATUS
>>
>
> When we run into things like this, what should our policy by? Should we
> also remove the code from trunk? From a 2.6/2.5 branch? Or do we
> leave code and functionality in that causes "concern" related to it
> being a back port, depending, of course, on what that concern *is*.
>

In this specific case, the concern is the default behavior change on a
non-release boundary, so a good action is something like an
upgrading.xml update.

There is already a docs@ bug for mentioning the current limitation.
-- 
Eric Covener
covener@gmail.com