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? > 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]
