I have completed the release process for .LRN 2.0.2 and OpenACS 5.0.4. I did the following testing:
Installing .LRN 2.0.2 from tarball works fine, and contains all new translations.
Upgrading .LRN 2.0.1 to 2.0.2 via repository works for all packages except dotlrn, which fails: https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=1633
I'm not sure how severe this is, but it may mean that 2.0.2 is a broken release. I am releasing it anyway because 1) it may be useful for new installs; 2) there may be a workaround for this, and I don't think it corrupts existing installs.
When doing the upgrade route, a few messages in forums and in survey don't get imported. This is probably because forums and survey weren't re-released - that is, I didn't batch-update the version numbers of all of the dotlrn-prereq packages (the packages in .LRN that aren't either OpenACS core or .LRN proper). Since the version number is unchanged, the system does not import new translations. These can be imported manually.
I have updated https://openacs.org/doc/openacs-HEAD/releasing-openacs.html with my notes from this process.
The main complicating factors:
1) I couldn't do bulk CVS operations on either dotlrn-core or dotlrn-prereq - I had to write shell scripts that cd'ed into each directory and ran cvs commands. Since openacs.org doesn't allow ssh keys, this meant that many operations entailed pasting my password into a running shell script process twenty or thirty times.
2) Since breaking all of the other packages from core, we've simplified core but left unsolved the problem of how to release the other openacs packages. This meant that I didn't have a firm idea of how to get the translations into all of the dotlrn-prereqs.
3) I don't currently have a way to generate change lists for a CVS branch, so that I can see all files changed between openacs-5.0.0 and openacs-5.0.4. This would be very helpful in reducing the need for testing - if you know only one file changed, the previous test results are still valid except for things affected by that file. I tried several packages and got some good results with cvs2cl.pl, but it spontaneously stopped working (spontaneously after a debian upgrade, I think).
4) Changes committed without any testing. If an upgrade script is committed without being testing, it's safe to assume that it's a broken upgrade script. If someone does not want to install a previous-version tarball and test the upgrade (a process which takes me about 10 minutes), they can use the upgrade test server (http://test.openacs.org/test/server?path=%2fvar%2flog%2fopenacs%2dinstall%2fcph03%2ecollaboraid%2enet%2dopenacs%2d5%2dup%2dpg%2dinstallreport%2exml). Log in as an admin via the provide link and then click upgrade (you have to have committed your code, tagged it openacs-5-0-compat, and upped the release number of the package in order for it to show up in install-from-repository. But you should be doing that anyway.)
