Versioning

Steve Loughran <[email protected]> Wed, 15 Mar 2006 13:15:13 +0000
Newsgroups gmane.comp.java.smartfrog.devel
Message-ID <[email protected]>
Hello,

I'd like to start some discussion about how to version components, 
though its too late to make major changes to how we do things for the 
next release.


First: why version libraries?
  -for ease of diagnosis of problems
  -to make it easy keep everything in sync.
  -so that we can store the files in the maven/maven2 repositories



For smartfrog, the two questions are
1. What version numbers should we give components?
2. How do we go about it?

Right now the answers are
1. the same as the smartfrog release
2. by running smartfrog, getting version information from it as return 
values and using that.

(2) seems neat, but it is slow and requires us to have the classpath to 
smartfrog before you can find out what version you need. Which is 
entirely at odds with how maven library management works, where you 
would ask for the smartfrog jar by version number. We will have to move 
to something property file driven instead.

In the phone conf, Kumar, Ritu and myself enumerated the options for 
giving things version numbers

a) no numbering at all
b) completely separate numbering for each component
c) number sequence for all the components, independent of the core
d) components in perfect sync with core, e.g. 3.04.008
e) components in sync with core, but can add intermediate releases, e.g. 
3.04.008-1, 3.04.008-2.

Option (a) is just a mess, and we dont want to go there.

Option (b) means every component has its own version sequence. This lets 
anything release on its own schedule but stops you seeing at a glance if 
things are synchronized. Once you have interdependent components (e.g. 
sf-www and sf-jetty), then it gets very complex.

Option (c) lets us release all components on a different schedule from 
the core

Option (d) restricts us to releasing components with the core. To 
release components, we release them with the core

Option (e) would let us follow the plan of (d), but allow interim releases.

What do people think we should do?

-steve







-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642