L.S.,
It looks like we gained consensus over the versioning of the components,
so I'll start making the necessary changes to the pom.xml files.
Regards,
Gert
Guillaume Nodet wrote:
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-tp18563641p18569130.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
