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]
