This is my understanding of how package developers are supposed to be using CVS right now.

• Package developers are supposed to essentially ignore the oacs-5-1 and oacs-5-2 etc branches, unless they're dealing with core packages. These branches are just for core. The reason for this is we've separated release of core and packages.

• Package bug fixes go to HEAD.

• New features can be worked on in separate branches and merged back into HEAD. These branches can be called whatever the heck you like, as long as it doesn't conflict with other branch names.

• Whenever you would like to make a release of a package, you use the APM to bump a version number, commit your work, and TAG it with a tag such as openacs-5-1-compat. So your work isn't released to the public until you tag it.

  tag -F openacs-5-1-compat

• The package repository builds the project repository based on the compat tags.

I guess what I'm looking for is guidance for what was left out of tip 61.

I've been told by more senior developers to commit packages to either HEAD or the oacs-5-1 branch. Different people tend to say different things.

The installation docs have people checkout packages using the compat tags. That makes development on either HEAD or the oacs-5-1 branch possible. So I guess either approach is acceptible, and that was why it was left out of TIP 61?

Other developers have expressed confusion. They would like some direction as to how to checkout packages and help contribute to them. Having two different systems makes it more complicated for them to get involved. People are asking me which branch they should check out, and I'm not really sure what to tell them. We don't really have a standard way of doing it.

Currently, I do my development on an OpenACS 5.1 installation (my developmental server). Once it is tested, I make a patch of my work, and patch the package in a checkout from HEAD, commit, and tag with openacs-5-1 compat. This allows me to make local edits in separate commits, but it does add some complexity. And it's not the most robust way of doing things.

I've asked in the past about the best way to set up CVS for development and production, to have local modifications, and still interact with OpenACS. The consensus seemed to be that CVS is not very good for this, and that everybody does it their own way, and no way is perfect, and darn wouldn't it be nice if we were all using Arch. I'd personally prefer to hear of one way that less experienced developers can default to while we learn the ropes, even if it's not perfect.

I'd like to write the documentation for this, so it's up there for everyone. But I'm still not totally clear on what the preferred way to do things is.

I second Jeff's explanation of branches being far more suitable to our release needs than tags. Another issue will be how to deal with bug fixes for oacs-*-compat. Do you just bump the tag with cvs tag -F ? That is imho a bad idea because you retain no history. It is also a real pain the further you get from the release since a bug fix won't be as simple as re-tagging the current HEAD file (it may have diverged).

Joel's comments in this thread seem to indicate that the packages will be part of the version branch, so what are the -compat tags for?

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.

Well, since nobody has commented on the RFC, Joel, would you mind TIPping this?

See http://openacs.org/forums/message-view?message_id=185506