> I am wondering if our svn structure is really suited > to the sub-project level releases, and tagging, we want to do? Somebody > help me out here....this is not a rhetorical question :-).
I think I just answered that in my previous email :-) > We could tag the entire repo for each sub-project release and tag, but > that seems sheer overkill to me. Since we haven't tagged yet, this > might be a good time to rearrange the repo as we need, once and for all. It's not overkill. That's your CVS training sneaking up on ya ;) It takes just a few bytes in the repository to do the tag, just a single svn command to run, and it is a lot easier to manage than several dozen trunks. The guidelines about trunk-per-project are more suited for less "granular" projects. Us java people with our many tiny component jars would get mad easily enough. Imagine how to get a sensible build tree for multiproject builds... > I hadn't thought about buildsystem actually. Take cornerstone for > example. there is a trunk/cornerstone/project-common.xml, that defines > the currentVersion as "1.2". In this case all the cornerstone > components are actuall being released as 1.2, so no problem. Let's say > we make a bug fix to sockets-impl...making it 1.2.1. When we release > sockets-1.2.1, do we also tag the parent directory and > project-common.xml? But, changing project-common.xml makes *all* > components go to 1.2.1. > > Same for Fortress....everything is 1.2, so if you fix Fortress-platform, > you need to release all Fortress JARs. Same with instrumentation, there > are others too. > > I propose doing away with project-common.xml(s), and let each project > stands completely on it's own. In any case, most project-common.xml(s) > have very little content anyway, there's not much we'll be duplicating. 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 ;-) 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. 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). It's the only way cocoon (which has way more separate components in there than we do) can make sure their release management requires only partial insanity. 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. If you're interested in the versioning problem in general, you might want to look at stuff like .Net, maven2 and the repository stuff the DPML guys are doing. You'll find it takes several iterations of months of hard work to get it "right". What a rant. Sorry! Summary: I advise to keep the number of versions to track and the number of independent components to release down to a sensible level. Don't try to "get it right", but aim for "some sort of useful, understandable and consistent versioning". My 2 cents from the peanut gallery, Cheers, Leo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
