Forum OpenACS Development: Re: RFC: Rules for Version Numbering and tagging of non-core packages

Joel, have you tried the CVS steps in question? Because I have not, but I suspect it is not "two steps instead of one", it might be more like N steps instead of one, where N is the number of non-core packages you care about.

However, as long as somebody's actually tested out using your "openacs-x-y-z-compat" CVS tagging convention, has concluded that in practice it doesn't cause trouble, and has specific instructions and examples of how to use it (which can later go into the docs), then sure, in that case it should be fine. In other words, I think the basic organization and strategy of your CVS tagging conventions above make sense, I'm just questioning whether anyone's checked whether in practice it is convenient and simple to work with, or if it causes extra trouble that might not be worth it.

The current package locations in CVS precisely mirror the locations they need to actually be in the CVS checkout in your filesystem in order to actually use those packages. This is a good thing. Malte, I'm not sure what you mean exactly with your "two trees" proposal (clarify please?), but if you mean changing the CVS repository around in ways which move packages into non-runnable locations, I don't really see why that would be worthwhile.

Oh! An alternate solution might be to just put the "openacs-x-y-z-compat" tag on both the core and non-core packages. I mean, a core package would still have the "openacs-x-y-zw" tag, but at the same location, it'd also have the "openacs-x-y-z-compat" tag. That gives one tag that is identical across all the latest packages compatible with a particular core release, regardless of whether those packages are part of the core release or not.

I'm sorry, Andrew, your alternate solution is simply too obvious to work.  :)
My idea is to use a non-core package repository as we do with dotlrn at the moment. If you want to have more than your usual set of packages, you can either install them using the webinterface or you can do a cvs checkout out of the non-core package repository. Each package could get a tag for each core-version it has been reported to work, so you could say:

cvs -d /non-core-cvsroot -r openacs-5-2 forums

This would allow in the long run to distribute packages not from the cvs repository at This might be good, if someone forks a package for a reason, that does not apply to everybody but a certain subset of OpenACS users.

But it does not have to be that way.

Andrew's suggestion is elegant. But there's no reason that the same "standardized" tag couldn't be used across isolated repositories as Malte suggested. And, the same version of a package could be tagged with multiple "compat" tags. Sounds pretty cool to me...