----- Original Message -----
> From: "Justin Ross" <[email protected]>
> To: [email protected]
> Sent: Monday, November 9, 2015 1:35:07 PM
> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>
> I'm late to this party.
>
> What would you all say to 1.35.0? 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.
+1 to 1.35.0
>
> 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]
> >
> >
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
