Leo,
There's three ways to do version management, the right way, the wrong way,
and the army way. Or something like that :-D
Versioning is a *hard* problem to get right. Being consistent at getting it
right is even harder, and as soon as you start being inconsistent meaning of
version numbers beyond "bigger as the previous one" quickly starts going
away.
What version of excalibur-datasource is compatible with what version of
excalibur-instrument? Can I use fortress-container-api v1.1.4 with
fortress-container-impl v1.2.1?
Historically we've never managed to get it quite right, despite trying
really really hard a few times. Reducing the number of versions and just
synchronizing them (like GNOME and affiliated projects do for example) might
seem silly, but it is a lot easier to get right.
Releasing all fortress jars with a new version number, knowing those
released jars are mutually compatible, is a lot easier than figuring out
that you need api version 1.1.4 with implementation 1.2.1, but 1.1.3 with
implemention 1.2.0. Especially three years from now. You've just witnessed
the horror it currently is to answer questions like that ;-)
I have seen it done both ways, and there are pros/cons as with all
practical things. The pro on more granular versioning is of course,
only what changes gets released. The con of course, as you say, is
correlating everything. But, I do agree, that it is simpler to release
related JARs together in the interest of keeping things simple to follow.
When porting excalibur to svn, we made the decision to reduce the number of
versions we keep track of. I tried to identify a few "groups" that might
make sense to version seperately so it wasn't a really big shock at first.
This comment was related to tagging the entire trunk or not, if we were
going to tag only components, then the problem was determining what tag
the project-common.xml would fall under. But, if we are tagging the
entire trunk, this is a moot point, everything gets the same tag.
I strongly recommend keeping it that way (even if just to keep sane), or if
changing it, changing it in the *other* direction (less seperately tracked
versions, not more).
In my release plan, I think I may have proposed that some components
have different version numbers than nthis would allow. I'll go back and
make sure Fortress, instrumentation, fw, components (+deprecated), and
cornerstone are the "groups" and everything within a group has the same
version. Sound OK?
Having a project-common.xml is a simple and common way to keep common
metadata common, but any alternatives are all fine with me, as long as it
works.
What a rant. Sorry!
No problem. Now, seriously, how do you really feel about versioning
everything on it's own?
:-)
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
