Torben:
"To reduce ambiguity..
cvs -z3 -d :pserver:mailto:anonymous@openacs.org:/cvsroot co -r oacs-5-1 openacs-4
pulls the versions you refer to?"
Yes. If you are developing, you must work from a branch checkout, not a tag. So you should be working from oacs-5-1 because, since it is a release branch for core, shouldn't be broken (much). If there is a blocking bug in core, you can simply pin the core modules to the last release (with cvs up -r openacs-5-1-0-final acs-kernel etc, for example).
The point about the OpenACS 5.1.1 tag applying across all packages is only meaningful for developers who are forking from OpenACS. For the last year or two, there hasn't been a single tag that applies across all OpenACS packages. This kind of tag is useful for 1) getting freestanding sites into source control and 2) making patches for your forked system. We had a tag for core, and a tag for .lrn, but no tag for standard packages which are required for .lrn but not in core, or for any non-core, not-.lrn packages. The OpenACS 5.1.1 tag will be applied to the most recent released version of everything on the oacs-5-1 branch (ie, I'll release 5.1.1 core, tag it oacs-5-1-compat, then check out oacs-5-1-compat, and then tag everything openacs-5-1-1-final). The point of jumping through the compat hoop, instead of just tagging the HEAD of oacs-5-1 as openacs-5-1-1-final, is that anybody who gets this tag or a tarball from it will be getting only released packages, not in-development packages.
