Keeping backported CHANGES in trunk CHANGES?

[Rainer Jung <ra...@kippdata.de>]

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.

Regards,

Rainer

Re: Keeping backported CHANGES in trunk CHANGES?

[William A Rowe Jr <wr...@rowe-clan.net>]

On Thu, Oct 18, 2018 at 5:21 AM Rainer Jung <ra...@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.