excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Excalibur Release Plan
Date Tue, 12 Apr 2005 13:47:29 GMT
> 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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org


Mime
View raw message