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
