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.
