Works for me.
> On May 29, 2020, at 3:30 PM, Ruediger Pluem <rpl...@apache.org> wrote:
>
> Reviewing our backport process I noticed that in many cases a clean merge via
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following
> way:
>
> 1. We create a changes-fragments directory (name to be determined) at the top
> level.
> 2. For each release we create a subdirectory such that we end up with the
> following structure:
>
> changes-fragments/
> 2.4.41/
> 2.4.42/
> 2.4.43/
> 2.4.44/
>
> 3. Each directory contains the changes for each release and each change entry
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in
> changes-fragments directories with the help of
> a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting
> CHANGES file as we like just like the x-forms commits
> for documentation plus this script is called by the release scripts from
> Daniel as part of the preparation of rolling a
> release.
>
>
> Regards
>
> Rüdiger
