Forum OpenACS Development: Re: Summary of Package development with CVS

5: Re: Summary of Package development with CVS (response to 1)

Posted by Mark Aufflick on 07/02/04 05:32 PM

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?

6: Re: Summary of Package development with CVS (response to 5)

Posted by Jade Rubick on 07/03/04 01:21 AM

I'm not sure about the compat tag. I'm curious to hear Joel's thinking about this. Currently, however, it IS important to use the -compat tags, because they set up what the package repository creates, I believe. So if you don't tag it, it's not available to many people. And I do update the tag (tag -F openacs-5-1-compat inside the project-manager directory).

For project-manager, I've copied all my HEAD changes to the oacs-5-1 branch as well.

I'll be doing all development on the release branches (currently oacs-5-1), and tagging with openacs-5-1-compat whenever things seem ready for release.

7: Re: Summary of Package development with CVS (response to 6)

Posted by Joel Aufrecht on 07/03/04 07:43 PM

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.

8: Re: Summary of Package development with CVS (response to 7)

Posted by Jade Rubick on 07/07/04 07:17 PM

Joel: that was exactly what I was looking for. It all makes sense to me.