Jade: "I guess what I'm looking for is guidance for what was left out of tip 61."
Consider this an RFC for changes to TIP 61.
- Rule 1.1 ("For non-core packages, developers should use their own judgment on when to deviate from the basic approach.") should be changed to
Developers should work on a checkout of the release branch of the lastest release. For example, if OpenACS 5.1.0 is released, developers should work on the oacs-5-1 branch. When oacs-5-2 is branched, developers should continue working on oacs-5-1 until OpenACS 5.2.0 is actually released.
Reasons: First, this ensures that developers are working against stable core code. Second, it ensures that new package releases are available to OpenACS users immediately.
- Rule 3.3 will be clarified with a link to
Naming Database Upgrade Scripts
- New rule: Rule 5. When a package is released in final form, the developer shall tag it "packagename-x-y-z-final" and "oacs-x-y-compat". x-y should correspond to the current branch. If the package is compatible with several different core versions, several compat tags should be applied.
Reason 1: The packagename tag is a permanent, static tag that allows for future comparison. The compat tag is a floating tag which is used by the repository generator to determine the most recent released version of each package for each core version. This allows package developers to publish their releases to all users of automatic upgrade without any intervention from the OpenACS release team.
Reason 2: The compat tags allows CVS users to identify packages which have been released since the last core release.
Reason 3: The compat tag or something similar is required to make Rule 6 possible.
- New rule: Rule 6. When OpenACS core is released, the openacs-x-y-z-final tag shall be applied to all compat packages.
Reason: This allows OpenACS developers who are creating extensively customized sites to branch from a tag which is stable, corresponds to released code instead of development code, and applies to all packages. This tag can be used to fork packages as needed, and provides a common ancestor between the fork and the OpenACS code so that patches can be generated.