Forum OpenACS Improvement Proposals (TIPs): TIP #46: (Approved) Rules for Version Numbering and CVS tagging of Packages

Collapse
1: TIP #46: (Approved) Rules for Version Numbering and CVS tagging of Packages
Posted by Joel Aufrecht on 02/04/04 10:38 AM

Proposal

I propose that these rules be adopted:

  1. Version numbering in all OpenACS packages follows Release Version Numbering engineering standard.
  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 discrepancies.
  5. Core module versions can lag behind the kernel during development but must all be synchronized 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. 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)
  9. Only core packages get openacs-* tags, except:
  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 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.

Reason

  • 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.

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.
Collapse
2: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 1)
Posted by Malte Sussdorff on 02/04/04 12:08 PM
I got a minor problem with 10). If I want to checkout OpenACS 5.2 then I need to issue two commands, on with the tag openacs-5-2-0 and one with the tag openacs-5-2-0-compat. Unless there is a compelling reason, don't have me do this.
Collapse
3: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 2)
Posted by Joel Aufrecht on 02/04/04 01:07 PM
No, you do a single cvs checkout with tag openacs-5-2-0-compat.

The core files are tagged twice in this scheme:
  - openacs-5-2-0
  - openacs-5-2-0-compat

And the files in an application, such as photo-album, are tagged:
  - package-2-0-0
  - openacs-5-2-0-compat

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.

Collapse
4: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 3)
Posted by Malte Sussdorff on 02/04/04 01:32 PM
Thanks for clarification. Second question arose. If it does not have any resemblence to Core and nothing is guaranteed to work together, why doe we tag the package "package-2-0-0" instead of "photo-album-2-0-0". Why do we tag them in the first place? The only concern to us should be the tag for the releases (openacs-5-2-0-compat) not additional arbitrary ones (at least this is my only concern, which has been solved). I don't mind putting your package tagging into place, but we should not enforce the tagging of packages except with the openacs-x-y-z-compat tag.

As I do not think seperate package tagging (either way) is an obstacle, I approve.

Collapse
5: Re: TIP #46: Approved by Dave Bauer (response to 1)
Posted by Dave Bauer on 02/04/04 05:28 PM
Approved
Collapse
6: Re: TIP #46: (response to 5)
Posted by Jeff Davis on 02/04/04 05:53 PM
I think it would be better to tag package releases with the package name since it's too easy to issue a "cvs tag package-2-0-0" in the wrong directory and tag the whole tree. With the package name in there at least it would be easy to fix.

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.
Collapse
7: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 1)
Posted by Tilmann Singer on 02/04/04 05:58 PM
Approved.

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!

Collapse
8: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 1)
Posted by Andrew Piskorski on 02/05/04 06:55 AM
The rest of Joel's proposal sounds good to me, but CVS tagging any OpenACS package with the literal string "package" is ugly and possibly error prone. Someone on the OCT please veto this TIP ASAP even if only for that single reason.
Collapse
9: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 8)
Posted by Joel Aufrecht on 02/05/04 09:01 AM
I changed the original TIP to reflect the unanimous feedback that the literal string "package" should instead be the package-specific package-key string.
Collapse
10: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 9)
Posted by Jeff Davis on 02/05/04 09:40 AM
well then I approve too.

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...).

Collapse
11: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 10)
Posted by Joel Aufrecht on 02/05/04 10:50 AM
No need to add extra hoops - we can keep using b tags into rc for now, and not start using rc tags until the release after we start understanding rc.  will that cover long upgrades - ie, if you go from 4.6.3 to 5.2 and the rc fix is in 5.1.1, will it work or will it require some kind of special reboot?
Collapse
12: Re: TIP #46: Approved (response to 11)
Posted by Lars Pind on 02/06/04 03:22 PM
Approved.

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.

/Lars

Collapse
13: Re: TIP #46: (Proposed) Rules for Version Numbering and CVS tagging of Packages (response to 1)
Posted by Don Baccus on 02/06/04 06:51 PM
Approved, with the caveat regarding upgrading ...