The way I see it is that these split out new version scheme is what's going to get used by the smx 4 container.. And based on your theory, it would confuse users if smx 4 were using smx 3 components :) AFAIK the biggest motivator to splitting out the components was so that they could get more easily used by the smx 4 distro.
Plus right now the 3.3-SNAPSHOT versions are being used by the components in the smx 3 trunk branch and I did not want to step on those deployments just yet, so it's safer to use a different version number, so why not go up to 4.0-SNAPSHOT. On Thu, Jun 19, 2008 at 3:40 AM, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > Hiram, > > Just one last remark: Is there any reason why the version number on the > components has changed to 4.0-SNAPSHOT? As long as ServiceMix 4 isn't > available, I think this will only confuse users -- seeing components with > version 4.0 will probably make them wonder what version of ServiceMix they > are using with that. I would suggest to keep the version at 3.3-SNAPSHOT > for now, as this will be the first version to contain the 'new' components. > Wdyt? > > Gert > > Hiram Chirino wrote: >> >> Hi Everyone, >> >> if you get a chance please review the 2 components ported over to the >> new per component release structure. >> >> Just checkout: >> >> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/ >> >> I'm happy with it. And I'm eager to do the same for the rest of the >> components in the smx3 trunk branch. Please let me know if I should >> hold of in doing the rest of the components. >> >> Should we do a release of the 2 that have been ported to test the >> release process? >> >> Regards, >> Hiram >> >> > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
