Forum OpenACS Improvement Proposals (TIPs): TIP #46: (Approved) Rules for Version Numbering and CVS tagging of Packages
I propose that these rules be adopted:
- Version numbering in all OpenACS packages follows Release Version Numbering engineering standard.
- 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
- All core packages released with the same version number.
- The kernel version is the ultimate authority in case of discrepencies.
- Core module versions can lag behind the kernel during development but must all be syncronized at each release.
- A version number for the core packages should be reflected both in the .info file and via cvs tags.
- 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.
- All other packages are versioned package-key-x-y-zw, where package-key and 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. (Emended from "All other packages are versioned package-x-y-zw, where x-y-zw are specific to each package" in response to feedback)
- Only core packages get openacs-* tags, except:
- 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 to both core and non-core packages. These tags can be moved for non-core packages as new versions of packages are released, so long as the new packages retain compatibility with the specified version of core.
- We don't have any ratified rules for numbering.
- We don't have a way to figure out which version of which package goes with core.
- 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.
The core files are tagged twice in this scheme:
And the files in an application, such as photo-album, are tagged:
One other thing that wasn't super-clear in my original post is that the package keyword is literally that, not a placeholder for, e.g., "photo-album" and "file-storage" and everything else. There should never be any file tagged photo-album-2-0-0. So if you checked out package-2-0-0 across the whole repository, you should get version 2.0.0 of each package, which bears no particular relationship to OpenACS core - it would be a meaningless thing to do.
As I do not think seperate package tagging (either way) is an obstacle, I approve.
I just don't see why you would want to have "package" as the tag. As you (joel) said:
So if you checked out package-2-0-0 across the whole repository, you should get version 2.0.0 of each package, which bears no particular relationship to OpenACS core - it would be a meaningless thing to do.
Tiny change request: tag packages with their name instead of 'package-' literally, so e.g. 'photo-album-2-0'. This should make it a little clearer for people looking at the repository and save them from thinking there is a general connection between two non-core packages with the same version number.
Thanks for specifying this!
One wrinkle though, the change to support rcN in versions requires a change to the plsql proc which compares version numbers, which means there needs to be an upgrade script. That upgrade will be a little tricky since you will need to upgrade the plsql proc before you go out to figure out which scripts to run (i.e. to upgrade you need to upgrade...).
Re Joel's last question, I'm afraid that this would indeed create problems with old installations.
We should go ahead and make the SQL function that determines this right away, so we get this new feature into the installed base as quickly as possible.
But we should not rely on it until we have determined, tested, and verified a solution that works for older installs as well.