I'd say that seems preferable to 1.0.0 in some key ways as you mention. It possibly still doesnt fully reflect the maturity thats there already, but it would at least reflect it somewhat.
Robbie On 9 November 2015 at 18:35, Justin Ross <[email protected]> wrote: > 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. > > 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]
