I wouldnt say I said that exactly ;) I don't actually mind too much what the version is, I mostly just had dislike for the date based versions suggested previously. I'd say there is an argument that had we ever changed from the 0.X versions to 1.0.0 at a more appropriate point previously then things would likely be well beyond that now, and so having any new numbering account for that somewhat wouldnt be the worst idea. That said, going back to the start, I don't overly mind what the initial new numbers are, im more interested in how they get used later.
Robbie On 9 November 2015 at 18:14, Chuck Rolke <[email protected]> wrote: > 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]
