On Wed, Nov 23, 2011 at 17:04, Jeremy Hughes <[email protected]> wrote:
> 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. > We would still be able to release per bundle, especially for bug fixes (we'd allow blueprint-core-0.4.0 and blueprint-cm-0.4.1 to coexist). But it's true that we could not release blueprint-core-0.5 without releasing blueprint-api-0.5. I'm not really concerned about ties between bundles inside a component. For those that want to make sure there's no strong ties, the uber-bundles are always available. > > 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). > Using snapshots is really a pain and having to sync across 5 projects is just not manageable. > > 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. > > Yes, that's right, I missed that. > > > > Thoughts ? > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
