On Mon, 2015-11-09 at 13:35 -0500, Justin Ross wrote:
> I'm late to this party.
>
> What would you all say to 1.35.0?
+1, although perhaps voting +1.99.9999 would better reflect the age and
maturity of this discussion, and its compatibility with previous
versions of the discussion.
> I favor the .35. part in order to (1)
> show the continuity with 0.34, and (2) suggest--correctly--that this
> is a
> mature component. I would consider this an optimization on top of
> the
> above proposed move to 1.0.0, which I like.
>
> Related notes:
>
> - Since for the foreseeable future the qpid::messaging API will
> remain in
> the qpid-cpp tree, I have come to think that qpid-cpp is in effect a
> library (among other things of course), and so deserves the major
> ("stable
> interface") number.
>
> - As implied already, in order to be consistent with the other Qpid
> components, I think we should go to simple increment-by-one versions.
>
> Justin
>
> On Mon, Nov 9, 2015 at 1:16 PM, Steve Huston <[email protected]>
> wrote:
>
> > +1
> >
> > > -----Original Message-----
> > > From: Chuck Rolke [mailto:[email protected]]
> > > Sent: Monday, November 09, 2015 1:15 PM
> > > To: [email protected]
> > > Subject: Re: Can the next release of the C++ broker and tools be
> > > 1.0.0?
> > >
> > > It has been moved and seconded that the C++ broker and tools be
> > > 1.0.0.
> > All
> > > in favor say 'aye'.
> > >
> > > +1
> > >
> > > ----- Original Message -----
> > > > From: "Robbie Gemmell" <[email protected]>
> > > > To: [email protected]
> > > > Sent: Monday, November 9, 2015 9:41:55 AM
> > > > Subject: Re: Can the next release of the C++ broker and tools
> > > > be 1.0.0?
> > > >
> > > > On 9 November 2015 at 14:11, Ken Giusti <[email protected]>
> > > > wrote:
> > > > > See inline:
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Robbie Gemmell" <[email protected]>
> > > > > > To: [email protected]
> > > > > > Sent: Thursday, November 5, 2015 9:22:07 AM
> > > > > > Subject: Re: Can the next release of the C++ broker and
> > > > > > tools be
> > 1.0.0?
> > > > > >
> > > > > > On 5 November 2015 at 13:52, Ken Giusti <[email protected]
> > > > > > > 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.
> > > > >
> > > > > Ah, yes - I recall that also. I've gotten that mixed up with
> > > > > the
> > > > > decision to use semantic versioning for proton + qpid
> > > > > -dispatch.
> > > > >
> > > > >
> > > > > Personally, I'm not a fan of the N.x versioning approach,
> > > > > even when
> > > > > it comes to a standalone service like qpidd/tools (e.g. not a
> > > > > library). As I mentioned above semantic versioning provides
> > > > > a bit
> > > > > more detail about the extent of changes in a given release.
> > > > >
> > > > > So the first question I should've asked is: Can we move
> > > > > qpidd/tools
> > > > > to semantic versioning?
> > > > >
> > > >
> > > > Sounds like a good idea to me.
> > > >
> > > > >
> > > > > > 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.
> > > > >
> > > > >
> > > > > That makes sense to me - hold off any changes to the
> > > > > versioning
> > > > > semantics/format until after qpidd/tools are moved to their
> > > > > own
> > > > > source trees.
> > > > >
> > > > >
> > > > > > 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).
> > > > > >
> > > > > > Robbie
> > > > > >
> > > > >
> > > > > Thanks for the info Robbie.
> > > > >
> > > > >
> > > > > > -----------------------------------------------------------
> > > > > > --------
> > > > > > -- To unsubscribe, e-mail: [email protected]
> > > > > > For
> > > > > > additional commands, e-mail: [email protected]
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > -K
> > > > >
> > > > > -------------------------------------------------------------
> > > > > -------
> > > > > - To unsubscribe, e-mail: [email protected] For
> > > > > additional commands, e-mail: [email protected]
> > > > >
> > > >
> > > > ---------------------------------------------------------------
> > > > ------
> > > > To unsubscribe, e-mail: [email protected] For
> > > > additional
> > > > commands, e-mail: [email protected]
> > > >
> > > >
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: [email protected] For
> > > additional
> > > commands, e-mail: [email protected]
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
