On Fri, May 29, 2020 at 9: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.
+1 from me, I don't volonteer for the scripts though :) Regards; Yann.
