Hi

more a general point (might be discussed already with 'the component
split'):

It's more about version numbers not the release process...

I'm not sure if this ends up in a version clutter because it's not clear
which version of (for example) ServiceMix works with which version of
servicemix-shared. For example I would expect that servicemix-shared version
4 works with ServiceMix 4 and servicemix-shared version 3 works with
ServiceMix 3. But here servicemix-shared version 4 works with SM3 and SM4.

So if we release servicemix-common, servicemix-shared, components, features
all in version 4 - could I use them all in SM3? ;-)
I think the 'similar looking' version numbers are confusing...

Just an idea: Why not release all "smaller" parts (servicemix-common,
servicemix-shared, components, features) with different version numbers
(Something like Ubuntu or http://lkml.org/lkml/2008/7/14/491) and only
release the 'big assemblies' with major version numbers (ServiceMix 4,
ServiceMix 3)?

Sorry but this was the first thing that came into my mind... ;-)

Kristian

2008/7/21 Freeman Fang <[EMAIL PROTECTED]>:

> Hi Guillaume,
>
> I'd like to release ServiceMix  3.2.2 once Camel 1.4 get released.
>
> Regards
> Freeman
>
>
> Guillaume Nodet wrote:
>
>> I'd like to start releasing a few things, mainly:
>>  * Kernel 1.0.0
>>  * Specs 1.0.1
>>  * servicemix-common / servicemix-shared
>>  * start releasing some of the components (there are some of thoses
>> that need a bit more work for OSGi, i'll keep the list posted)
>>
>> Camel 1.4 is nearly out, so we can also think about releasing
>> ServiceMix 3.2.2 (finally).  Any volunteer for this one or the above ?
>>
>>
>>
>
>
-- 
GASwerk - Geronimo Application Server Assemblies
http://gaswerk.sourceforge.net

Reply via email to