+1 this would be the best naming imho.
Regards Lars Am Montag 25 August 2008 10:39:03 schrieb Guillaume Nodet: > I'd like to revive this discussion as I think we should start > releasing the components asap. > I no one has any better idea, we could go for xxxx.yy, where xxxx is > the current year, and yy an incrementing counter. > The first release would then be 2008.01 and the next one 2008.02, etc... > Thoughts ? > > On Wed, Jul 23, 2008 at 8:06 AM, Kristian Köhler > > <[EMAIL PROTECTED]> wrote: > > A version number like 2008.01 looks good to me. > > > > Splitting the version number scheme for the components from the scheme > > used for the assemblies is just an idea.. I'm not sure if we 'definitely' > > need it. I think I could make things clearer... > > > > I'm torn between the current version scheme and a possible new one. > > > > Any other comments? > > > > Kristian > > > > 2008/7/22 Guillaume Nodet <[EMAIL PROTECTED]>: > >> The 8.8 numbering seems a bit confusing to me, as it is not obvious > >> that the date is used. The consequence is that people will be > >> confused about major versions change, etc... > >> So I'd rather have 2008.01, so that it becomes more obvious that the > >> first part is a not a major version number. > >> > >> On Tue, Jul 22, 2008 at 8:11 AM, Kristian Köhler > >> > >> <[EMAIL PROTECTED]> wrote: > >> > Thanks Gert ;-) > >> > > >> > I thought a lot about it and I think what confuses me (and perhaps > >> > some others) the most is the fact that the components have a similar > >> > looking version than 'one container' (ServiceMix 4). My first thought > >> > is to use component version 4 in ServiceMix 4 because there is a > >> > version 3 which > >> > >> works > >> > >> > with ServiceMix 3. > >> > > >> > Not sure if this justifies a reversioning of the components but this > >> > >> would > >> > >> > make things clearer IMHO. ;-) > >> > > >> > The idea is to use a separate version scheme for all parts which are > >> > used > >> > >> in > >> > >> > SM3 and SM4 (components, shared, common). The scheme might look like > >> > what Gert described (2008.01 or 8.1 (first release) or 8.8 > >> > (2008/aug)). > >> > > >> > Perhaps this is a temporary issue while we ship two versions of > >> > ServiceMix... > >> > > >> > After all I think we should ship SM 3.2.2 as soon as possible ;-) > >> > > >> > Kristian > >> > > >> > 2008/7/21 Gert Vanthienen <[EMAIL PROTECTED]>: > >> >> L.S., > >> >> > >> >> I don't think Kristian is proposing not to give any version numbers > >> >> to > >> > >> the > >> > >> >> components, but rather not to give them a version number that can be > >> >> confused with any given container's version number -- using something > >> > >> like > >> > >> >> years/months in the versioning instead. Let's say for a moment we > >> >> give > >> > >> all > >> > >> >> the components an initial version of 2008.01 right now to indicate > >> >> the first > >> >> release of a component for 2008. > >> >> > >> >> That still leaves Bruce's suggestion for using code names for the > >> >> major releases of SMX 3 and 4. We could have a ServiceMix 3.3 'Isis' > >> >> release that > >> >> contains the 2008.01 version of this component as well as ServiceMix > >> >> 4.0 'Ra' release shipping with the same version of the component. > >> >> This way, users wouldn't get confused over the version of the > >> >> component not > >> > >> matching > >> > >> >> the version of the container, because they would at first glance > >> >> notice that > >> >> these things use completely different versioning schemes. > >> >> > >> >> Am I getting this right, Kristian? Actually, I like the idea. > >> >> Instead > >> > >> of > >> > >> >> wondering whether we version the components 3.x or 4.x to cause the > >> > >> least > >> > >> >> confusion as we have done before, we just version them entirely > >> >> different... > >> >> > >> >> Regards, > >> >> > >> >> Gert > >> >> > >> >> gnodet wrote: > >> >> > servicemix-shared and all components should work on any version of > >> >> > the servicemix jbi container, be it 3 or 4. They should also work > >> >> > in any other JBI container as well (such as OpenESB or Petals). > >> >> > Wrt the versioning, given the point above, I'm not sure how to > >> >> > handle that. I don't think restarting to 1.0 is a good idea, as > >> >> > these parts are already released, so it would be very confusing > >> >> > imho. That said, we could either go with 3.x or 4.x. > >> >> > I'm not sure about not giving numbers at all for components. Bruce > >> >> > suggested some time ago to use code names for our "big releases", > >> >> > which would be the opposite to what you suggest ... > >> >> > > >> >> > On Mon, Jul 21, 2008 at 1:41 PM, Kristian Köhler > >> >> > > >> >> > <[EMAIL PROTECTED]> wrote: > >> >> >> 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 > >> >> > > >> >> > -- > >> >> > Cheers, > >> >> > Guillaume Nodet > >> >> > ------------------------ > >> >> > Blog: http://gnodet.blogspot.com/ > >> >> > >> >> ----- > >> >> --- > >> >> Gert Vanthienen > >> >> http://www.anova.be > >> >> -- > >> >> View this message in context: > >> > >> http://www.nabble.com/-DISCUSS--Start-releasing-a-few-things-tp18563641p > >>18569130.html > >> > >> >> Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > >> > > >> > -- > >> > -- > >> > GASwerk - Geronimo Application Server Assemblies > >> > http://gaswerk.sourceforge.net > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > > > > -- > > -- > > GASwerk - Geronimo Application Server Assemblies > > http://gaswerk.sourceforge.net
