qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: Changing the release numbering scheme (was Re: [VOTE] Version Numbers)
Date Tue, 10 Feb 2009 22:09:37 GMT
I can understand the various views of what we need to achieve to call Qpid a
more complete product. I agree with many of the goals put forward and I'm
glad we're discussing them.

However, we have been on the go with releases that users have deployed into
production since 2006. For me, the notion that we're less than 1.0 is
somewhat nonsensical given production applications of Qpid and the
robustness & reliability of the Java components (at least, other elements
outside my ken).

The clients/brokers have historically interop-ed and we have made some poor
decisions subsequently. I'm not sure that takes us directly backwards.

However, this is not an area I'm that passionate about. I guess my point is
that I think we need to be careful about putting too much significance on
the "version number as project description" view.

We absolutely do need to have a coherent set of project goals, including
inter-op, API changes, feature compability etc. Essentially the numbering of
our releases will not be that significant to our users (I am never, ever
asked about the number - a comprehensive test suite with published results
benchmarked would be a far more compelling argument for use.)

I'd find it hard to explain to users with production deployments that we're
somehow a less than 1.0 product. For me, we're hanging other (important)
project discussions off the wrong hook.

My tuppence ...


On Tue, Feb 10, 2009 at 9:56 PM, Robert Greig <robert.j.greig@gmail.com>wrote:

> 2009/2/9 Aidan Skinner <aidan@apache.org>:
> >> I think it would be good to have a discussion - hopefully leading to
> >> consensus (!) - on what people think we need to have achieved to merit
> >> a 1.x release. To my mind, if people agree those items and they are
> >> different from what is in scope in our next release, that implies we
> >> don't have the correct focus for our next release(s).
> >
> > I think that's a separate issue. We do need to talk about our release
> > process a bit more, but that's probably best done in another thread.
> > Possibly this one: http://markmail.org/message/5bxobdc23rgbmqu7
> Well, people seem to have a view that we need to have certain features
> (APIs, protocol compatibility) to be able to have an X.0 release so I
> think it is directly related.
> I don't think it's related to our release process though?
> >> My own view is that Mx is a weak numbering scheme - something I have
> >> always felt and I have no idea why incubator projects have to be
> >> numbered (or should I say encumbered) in such a way. I am not sure
> >
> > They're not. I'm not sure where that idea originated, but it's never
> > been a requirement for podlings to release Mx numbered artifacts. I
> > think the "all podling release have to be M.x releases" fallacy is an
> > instance of the monkey/hose/banana problem[1].
> Interesting, I wonder how we ended up with such a poor numbering
> scheme in the first place. Anyway, that is a historical detail now I
> suppose.
> RG
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message