+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]
