Agreed, having the additional version information beyond the 1.0.0 allows us to tell the story of where this came from and why it is indeed a mature release.
On 11/09/2015 01:52 PM, Robbie Gemmell wrote: > 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] > > -- Tim Bish Sr Software Engineer | RedHat Inc. [email protected] | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
