Hi Kristian,
I cast my vote for lightweight processes. Of these choices, option (c)
sounds best to me.
Even better and lighterweight would be to separate this log into its own
file. The maven script could automatically add an entry to the end of
this log every time a release is published. The release manager could go
back and edit the log in case something went wrong. But normally the
maintenance of this log would be handled by the script and the release
manager would have one less step to worry about, addressing Knut's
issue. I have started putting logic into the the ant build scripts to
automate some of these tasks which involve updating files in the repository.
I agree that most developers won't care about this file. It is
interesting archeology for release managers, though.
My $0.02,
-Rick
Kristian Waagan wrote:
Hi,
When I worked on the scripts generating and publishing the Maven 2
artifacts, I added a release history to the maven2/README.txt file.
This file exists on every branch.
I did not think a lot about how this would work out as we publish new
releases. Its only purpose is to serve as a record for artifacts
released by the Derby community. I don't think Derby users will read
it. Keeping it up to date on all branches seems like a drag. Here are
some options, including the tedious one:
a) Update trunk, merge to all branches.
b) Update trunk, merge to release branch.
Merging may not work here, so we may have to simply update the
file directly on both trunk and the release branch.
c) Update trunk only.
I have chosen to always update trunk so that we have a place where we
keep the full history.
Any opinions on this?
I'm leaning towards (c) for simplicity. I prefer to avoid (a).
Regards,
