Forum OpenACS Development: RFC: Rules for Version Numbering and tagging of non-core packages

Problems I'm trying to solve:

• How does an OpenACS admin know which versions of which packages are compatible with their version of OpenACS Core? Assuming most admins use the repository, this problem is the same as, how do we build a repository channel with the most recent compatible version of each package?
• How are non-core packages versioned?

Proposed Rules

1. I have updated the Release Version Numbering engineering standard to reflect current practice.
2. The core packages are acs-admin, acs-api-browser, acs-bootstrap-installer, acs-content-repository, acs-core-docs, acs-kernel, acs-mail, acs-messaging, acs-notification, acs-reference, acs-subsite, acs-tcl, acs-templating, acs-service-contract, search, automated-testing, acs-authentication, ref-timezones
3. All core packages released with the same version number.
4. The kernel version is the ultimate authority in case of discrepencies.
5. Core module versions can lag behind the kernel during development but must all be syncronized at each release.
6. A version number for the core packages should be reflected both in the .info file and via cvs tags.
7. CVS tags for core packages follow the scheme openacs-x-y-zw (see the Version numbering doc linked above for details). These tags are historical markers and should not usually be moved.
8. Only core packages get openacs-* tags
9. All other packages are versioned package-x-y-zw, where x-y-zw are specific to each package and not correlated to any other package or to OACS core. These tags are also historical markers and should not be moved.
10. The newest version of each package which is compatible with each version of OpenACS since 5.0.0 is tagged openacs-x-y-z-compat. These tags apply only to non-core packages. These tags can be moved as new versions of packages are released, so long as the new packages retain compatibility with the specified version of core.

Implementation

• We are already following this scheme for core.
• We needn't bother to retroactively tag anything; the basic goals are satisfied if we simply start tagging new package releases as we go forward.
• The repository generation code (and package inventory list generation code) needs to know this naming scheme and generate packages accordingly.

However, as long as somebody's actually tested out using your "openacs-x-y-z-compat" CVS tagging convention, has concluded that in practice it doesn't cause trouble, and has specific instructions and examples of how to use it (which can later go into the docs), then sure, in that case it should be fine. In other words, I think the basic organization and strategy of your CVS tagging conventions above make sense, I'm just questioning whether anyone's checked whether in practice it is convenient and simple to work with, or if it causes extra trouble that might not be worth it.

The current package locations in CVS precisely mirror the locations they need to actually be in the CVS checkout in your filesystem in order to actually use those packages. This is a good thing. Malte, I'm not sure what you mean exactly with your "two trees" proposal (clarify please?), but if you mean changing the CVS repository around in ways which move packages into non-runnable locations, I don't really see why that would be worthwhile.

Oh! An alternate solution might be to just put the "openacs-x-y-z-compat" tag on both the core and non-core packages. I mean, a core package would still have the "openacs-x-y-zw" tag, but at the same location, it'd also have the "openacs-x-y-z-compat" tag. That gives one tag that is identical across all the latest packages compatible with a particular core release, regardless of whether those packages are part of the core release or not.

cvs -d /non-core-cvsroot -r openacs-5-2 forums

This would allow in the long run to distribute packages not from the cvs repository at OpenACS.org. This might be good, if someone forks a package for a reason, that does not apply to everybody but a certain subset of OpenACS users.

But it does not have to be that way.

If in your packages directory, you have package A checked out from one CVS repository and package B checked out from another, doing CVS operations withing either package A or B will work just fine, but doing any operations across both package A and B at once (e.g., "cvs -nq up") will not work. At least, it didn't work when I just tried it.

The packages directory has a CVS/Root file too of course. Let's say that it points to repository-A, but package-B is checked out from repository-B instead. Well, repository-A doesn't have any packages/package-B directory, so when CVS sees package-B, it just silently skips it. The fact that packages/package-B/CVS/Root points to a different yet valid repository makes no difference.

For any real site you'd already have vendor imported everything into your own CVS repository anyway, so it doesn't matter there. What about OpenACS developers doing stuff that requires co-ordinated change across multiple packages? Malte says dotLrn CVS is set up that way now, so re-factoring and moving code from dotLrn into OpenACS should be a good test case. You guys who've done any of that, are you ok with the way CVS has worked for you there?