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-tp18563641p18569130.html Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
