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]
