On 01/20/2015 03:57 PM, Steve Huston wrote:
-----Original Message-----
From: Gordon Sim [mailto:g...@redhat.com]
Sent: Tuesday, January 20, 2015 10:49 AM
To: users@qpid.apache.org
Subject: Re: Qpid C++ and Python 15.02 - Alpha approaches
On 01/20/2015 03:37 PM, Justin Ross wrote:
http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release-
td761
7054.html
Yes, the generally agreed goal is to move away from "0." for our now
mature components. I don't think any suggestion was made about Proton.
Most participants on that thread favored a YY.MM (Year, Month) scheme,
so that's where I started.
The main advantage I see from the year/month scheme is the ability to relate
different component versions to each other. E.g. 15.06 of component X was
released at the same time 15.06 of component y was, but after 15.01 of
component z and before 15.12 of component, um, a, lets say.
Ok, but a month is a long time and if components aren't released "together"
then both in the same month may not mean much.
Yes, but I would hope they would be at least compatible and somewhat
tested against each other, if they are planned for the same month.
Of course the time taken to actually get ready for release may vary, and
one will go out before the other, but the changes to the later
components release should not be so extensive as to break things.
Our current testing across/between components is not very good. I would
hope however that going forward, everything released would be tested
against the last release of other relevant components.
I.e. you really only get benefit out if this if it is used fairly broadly across
components that are released at different times.
While I see some advantage from this scheme, there are different
advantages for other schemes so I have no desire to impose this it.
However if there isn't sufficient agreement to use it more widely than just
the qpid-cpp and related bits, I'm not sure it has much advantage (and it is
definitely a bit unusual).
It is unusual. Not necessarily bad, but it will require more explanation and
attention because of the confusion it would cause.
Also, what do we mark JIRA entries with for "fix version"? If we don't know the
time a next release will come, it's hard to mark the next release, and our current
odd-even won't work any longer either. It's important to be able to tell when a bug was
fixed.
One thing I do think is essential is a clear, public release schedule
for each component. (That can of course be updated as necessary, with
the community as whole consulted and kept in the loop).
This along with the commitment to do a reasonable level of interop
testing for every released component is the only thing I feel strongly
about. The versioning scheme is not as important if we do those.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
