On 23 November 2011 14:13, Guillaume Nodet <[email protected]> wrote: > Given we don't follow semantic versioning until the API is stabilized (so > 1.0.0), can we agree on a better set of rules for in the mean time ? > > I'd propose the following: > * on a given component (blueprint, application ,etc...), use the same > version for all packages and bundles
That would imply we wouldn't release by bundle, but by 'component' aka top level module. The thought was if we practiced getting the semantic versioning right before we go to 1.0.0 we'll have a better chance of it succeeding when we do get to 1.0.0. I have to admit it's been fairly tortuous getting per-bundle semantic versioning releases to work. I still think it's the right thing long term. Maybe this is just a maturity thing and getting it to work on a per-component basis first may help us get releases out more quickly in the short term. My concern is we may end up with the bundles in a component being too tightly coupled and pulling them apart again for 1.0.0 becomes very hard. Once we have had a short run of 0.x releases with no deprecations then I think we can move to 1.0.0. That said, I think some of the difficulties in consuming the latest release have been down to API changes rather than the semantic versioning approach. Since 0.x is subject to API change at any time, I would have thought having a continuous integration of the trunks of CXF / Karaf / Aries would be good to ensure things don't get too broken (for long). I'm warming to this idea, purely because it is pragmatic and helps consumers in the near term. I'd like to hear others' thoughts first though. > * make sure we use a tight range [0.4, 0.5) for importing aries packages > because we allow breaking compatibility in minor releases (it also gives > place to point releases) This is the case in the latest Blueprint release. The JNDI, JPA, Transaction and I believe Application modules are done like this too - I believe Tim Ward put those changes in. > > Thoughts ? > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
