One more question: The scheme depends on actually knowing what changes have been made to the code. I.e. what is the minimum version number (major, minor or patch) we must increase?
Ideas?
I know that Cocoon creates a whole new repo for each bump in minor version number.
We could do something similar - perhaps have a
avalon/framework-4.1 directory and a avalon/framework-4.2 dir.
I don't think this necessary. If the CVS is tagged with a specific version release you can maintain separate builds (for example I've got a merlin and assorted sub-systems checkout all relative to 3.2.5 and another checkout all relative to head).
Right after a release I'm typically bumping any package I modify to X.Y-SNAPSHOT. As changes progress I'll update X and Y to reflect backward compatibility (for example both activation and composition packages have been bumped to 2.0-SNAPSHOT as changes are not backward compatible with 1.X).
Cheers, Steve.
/LS
From: Leo Sutic [mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
