Marnie McCormack wrote:
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.
I'm not sure I fully understand what you're saying. My assertion is
quite simple. The Mx releases don't promise any sort of interoperability
between Mx and Mx+/-1. This makes QA for these releases comparatively
easy since we only need to test that we have a self consistent and
working snapshot in order to release.
As soon as we start introducing the notion of point releases, whether
it's something like 1.5, 1.6, or whether it's M4.0.1, there is an
implied promise of interoperability that most people will expect given
the chosen release numbering convention, and it's something that we
don't currently test for at all. In fact as far as I'm aware most qpid
developers pretty freely make code changes without worrying about
backwards compatibility at all.
If what you are suggesting is that we need to start thinking about when
and how to provide higher levels of interoperability, then I do agree
that this is something that we need to address at some point and will
certainly need some careful thought, however I would still assert that
this implies more testing and therefore more work, so I'm confused at
the idea that introducing this sort of point release would make anything
easier.
On the other hand if you're suggesting there is a specific piece of work
you'd like to fast-track to a released state (e.g. 0-10 support in the
Java broker), then I'd say we should discuss that concretely and figure
out the best way to handle it. For that case specifically I could
certainly see doing a component level release assuming we were clear up
front about exactly what interop testing we were/weren't doing, and we
named the release accordingly.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
