On 2 December 2014 at 21:59, Chuck Rolke <[email protected]> wrote: >> I feel like for qpidd and qpid::messaging at least, a '1.0' at this >> point is meaningless and even perhaps confusing. They are both well past >> that really, placing a high priority on stability and backward >> compatibility. The 1.0 label to me is more appropriate for newer >> components like proton, dispatch-router and the new JMS client. > > There's a certain appeal to having the version number be the year.month > that the product was branched especially if we have four or five > closely related products. If some whizzy feature of the broker > is released in 15.4 then you know that it probably isn't supported in > dispatch 15.2. There's no way to know that if the broker is 3.2 and > dispatch is 1.1.
I'm not sure that really holds if things are being released independently. I think it can be clearer in some cases, but is often going to be more confusing as well. Unless their release dates match and they co-developed a brand new feature, one component quite likely supported something to do with the feature before the other, in which case the versions wont match anyway. Backporting might later mean support for something gets added to prior <Year.Month.Patch> releases for one component but not the other, leading to further mismatch (and other things such as odd looking releases that dont match the year or months in their version). > > My preferences in order are: > > 1. All products with 'year'.'month'. > 2. All products switch to 3.1 on next release and increment independently. > > --------------------------------------------------------------------- > 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]
