I'm working to move stuff I developed on the 3.2.5 platform to 5.x, but I'm not in a particular hurry, and I want to target where OpenACS is going to be in the future, not where it is right now -- so I don't have to play the upgrade script game before I even deploy. (The periodic "move CR features into acs_objects" discussions suggest that there are some basic core changes coming down the line -- though maybe that time is far off, I don't know.) This is why I want to work with a HEAD system, not a branch. (That and the fact that no one is supposed to use HEAD for production, so breaking things temporarily isn't such a critical concern.)
What I thought I'd do for CMS (and for FS for that matter) would be to merge the oacs-5-2 stuff into HEAD just to get the new/fixed code up there. This has been done periodically (isn't it usually Jeff who handles this?) at a new branch release (so all the bug fixes get merged to HEAD), but shouldn't it happen whenever someone makes some substantive improvements to a package on a branch?
Put another way, I want to be working with etch or even with sid -- and not sarge -- since by the time I need it, the release I use will be "stable" and not "testing" or "unstable". Or am I mistaken entirely here about the parallel between OpenACS and Debian releases?
I seem to recall that you use a complex mixed system(s) at your company, so these are issues that you obviously grapple with -- and have figured out? How do you mix different versions of core and non-core packages from cvs checkouts?