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

If we use the same tag for core and for compatible, it's easier to confuse the core, historical tags with the per-package floating compatibility tags - we are using the same syntax for two different semantics.  If we do it the other way (the way in the RFC), we keep that distinction clear but broad cvs checkout by version becomes two steps instead of one.
Why don't we use two trees then? One ACS-Core tree, that should get you started so you could install packages from the OpenACS Repository over the web and one for the packages.

For each release we keep a matrix of *reported & tested* package versions (either .info file or cvs tag).

This way we can name the packages any way we want. The Repository will only generate the packages based on the Matrix. The matrix will be filled by OpenACS users.

Which brings up another idea. Automated error reporting by websites. I know, we might as well first get our hands on reporting installations back to the system. But if we'd log all error messages with a package_key and have a sweeper on the error log, to see which packages generate errors, we could automatically report back which package version works with what core version and which does not. Though we'd have to make sure the files have not been changed after the download from the repository. Well, most likely too much work to implement.....