RE: Versioning

+1 for c.

They really are independent entities.

> -----Original Message-----
> From: smartfrog-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:smartfrog-
> developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Steve Loughran 
>
> 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
> _______________________________________________
> Smartfrog-developer mailing list
> Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/smartfrog-developer



-------------------------------------------------------
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&kid0944&bid$1720&dat1642