qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Can the next release of the C++ broker and tools be 1.0.0?
Date Thu, 05 Nov 2015 14:22:07 GMT
On 5 November 2015 at 13:52, Ken Giusti <kgiusti@redhat.com> wrote:
> Folks,
> Given that we're able to release qpid-tools and qpidd broker independently for the API
libraries, isn't it about time we bestow the honor of a 1.0.0 version to these packages?
> These packages do not offer a "public API" as the libraries do, so technically semantic
versioning rules don't apply. But those rules do define a major release of 0 (eg. 0.Y.Z) as
being an "initial development release".  Furthermore, that's the common public perception
of any software released with a 0.x.y version, IMHO.
> For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to the point where
existing functionality is stable.  If we were to deprecate features, we'd want to increment
the X factor anyways, so at some point we really have to move beyond 0.x.y.
> qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or flying cars, right?
> --
> -K

Prior discussion on this (perhaps a year ago?) was that the qpid-cpp
version would indeed be changed, probably to something like 33.0 (at
the time), i.e move the dot[s] from prior release number cadence as a
starting point. The idea was also discussed to move the components to
their own source trees aligned on what would be released together
(independently of other bits), in this case having the cpp broker and
its tools in the same tree was proposed.

The proposed relocation work was done for the Java bits (initial
independent release with new version yet to happen, but is slated soon
as 6.0.0), and such alignment was implicit from the start for things
like proton/dispatch/jms. Nothing had changed in that regard for the
other components since those discussions, so when the most recent
qpid-cpp release was desired I simply continued with 0.34 from the
previous version scheme. I think it makes sense the first new version
should be used after such changes are made. I did create/rename a
bunch of separate versions in JIRA using '-next' versions in keeping
with desire to move them away from the previous versioing scheme in
future (and reflect the next release/version numbers not being decided
in all cases).


To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message