Forum OpenACS Development: Re: RFC: Rules for Version Numbering and tagging of non-core packages
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.
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 OpenACS.org. 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.