I'd put the opposite view forward - we are currently unable to avoid doing releases with non-interop-ing components and are also duty bound to test against old broker/client releases (we do this for each release).
Thus I think component releases should not present a problem - we could, of course, introduce a quality gateway that the release manager would own i.e. version blah of this component has been tested against versions 1,2,3 of other components A,B,C. For example, if the 0-10 work on the Java broker got committed tomorrow we'd be mad not to release it asap. It's probably unreasonable to force all the components, with widely differing roadmpas, to conform to one release schedule. It'd surely (please god) be simpler to get our releases out with a single or smaller set of component parts. Bfn, Marnie On Fri, Jan 30, 2009 at 1:12 PM, Rafael Schloming <rafa...@redhat.com>wrote: > Martin Ritchie wrote: > >> I thought we agreed at the end of last year that we were going to move >> to release by components rather than language. e.g. >> Brokers >> qpid-c++-broker >> qpid-java-broker >> >> Clients >> qpid-c++-client >> qpid-dotnet-client >> qpid-java-client >> qpid-ruby-client >> qpid-python-client >> >> Management >> qpid-management-cli >> qpid-management-eclipse >> qpid-management-qman >> ... >> >> That way if a user only wants to have the C++ broker and Java client >> they only need download those components. It also makes it way easier >> to say. Hey new version of component X now available.That said, We >> should still have a full release of version X.0.0 with all components >> but then allow each component to do point releases as is needed for >> bug fixes, small enhancements, but fully compatible. >> > > I'm fine with doing *packages* by component, but assuming I'm remembering > the correct thread, I don't think we agreed to doing *releases* by > component. There are significant problems with doing point releases of a > component. In particular, any change to a broker would require retesting > against each minor version of all the clients, and similarly a change to one > of the clients would require retesting interop against each minor version of > all the other clients. This very quickly leads to combinatorial explosions > of testing, and would be more work than simply doing a full release where we > don't need to (or at least we don't usually) worry about breaking > compatibility with deployed clients from older releases. > > > --Rafael > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
