[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: Keeping backported CHANGES in trunk CHANGES?
From:       William A Rowe Jr <wrowe () rowe-clan ! net>
Date:       2018-10-18 12:56:09
Message-ID: CACsi250zSh4FgojwomUE0ShcFgqsiWsLDhMHz42p_+cJvCFK7g () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 18, 2018 at 5:21 AM Rainer Jung <rainer.jung@kippdata.de> wrote:

> In trunk we do now have a 2.5 CHANGES file, ie. the file contains
> entries for 2.5.0-alpha and the entries above those under the 2.5.1
> heading.
>
> I think we should add entries under 2.5.1 even if things get likely
> backported and such items should no longer be removed when being
> backported. Before 2.5.0-alpha, that was just a candidate CHANGES file
> for the things not in 2.4.x, but now it should also document the changes
> after 2.5.0-alpha. Similar to how I think it was done while switching
> from 2.2 to 2.3/2.4.


That would make sense, note 2.5.0-alpha did not receive a successful
release vote, so we are still on the ground floor, so to speak.

We really need some logic to keep the two CHANGES files in-sync. The
end result, in 2.6.0, would be to have everything applicable listed as its
public/GA change from 2.4.x revision on, with everything strictly in the
alpha/beta 2.5.x change cycles listed under their respective update.

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 18, 2018 at 5:21 \
AM Rainer Jung &lt;<a \
href="mailto:rainer.jung@kippdata.de">rainer.jung@kippdata.de</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">In trunk we do now have a 2.5 \
CHANGES file, ie. the file contains <br> entries for 2.5.0-alpha and the entries \
above those under the 2.5.1 heading.<br> <br>
I think we should add entries under 2.5.1 even if things get likely <br>
backported and such items should no longer be removed when being <br>
backported. Before 2.5.0-alpha, that was just a candidate CHANGES file <br>
for the things not in 2.4.x, but now it should also document the changes <br>
after 2.5.0-alpha. Similar to how I think it was done while switching <br>
from 2.2 to 2.3/2.4.</blockquote><div><br></div><div>That would make sense, note \
2.5.0-alpha did not receive a successful  </div><div>release vote, so we are still on \
the ground floor, so to speak.<br></div><div><br></div><div>We really need some logic \
to keep the two CHANGES files in-sync. The</div><div>end result, in 2.6.0, would be \
to have everything applicable listed as its</div><div>public/GA change from 2.4.x \
revision on, with everything strictly in the</div><div>alpha/beta 2.5.x change cycles \
listed under their respective \
update.</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]