Sorry to chime in late on this - I saw the discussions going by in December but paid no attention as I was mostly not working then.
> -----Original Message----- > From: Gordon Sim [mailto:g...@redhat.com] > Sent: Tuesday, January 20, 2015 10:49 AM > To: users@qpid.apache.org > Subject: Re: Qpid C++ and Python 15.02 - Alpha approaches > > On 01/20/2015 03:37 PM, Justin Ross wrote: > > http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release- > td761 > > 7054.html > > > > Yes, the generally agreed goal is to move away from "0." for our now > > mature components. I don't think any suggestion was made about Proton. > > > > Most participants on that thread favored a YY.MM (Year, Month) scheme, > > so that's where I started. > > The main advantage I see from the year/month scheme is the ability to relate > different component versions to each other. E.g. 15.06 of component X was > released at the same time 15.06 of component y was, but after 15.01 of > component z and before 15.12 of component, um, a, lets say. Ok, but a month is a long time and if components aren't released "together" then both in the same month may not mean much. > I.e. you really only get benefit out if this if it is used fairly broadly > across > components that are released at different times. > > While I see some advantage from this scheme, there are different > advantages for other schemes so I have no desire to impose this it. > However if there isn't sufficient agreement to use it more widely than just > the qpid-cpp and related bits, I'm not sure it has much advantage (and it is > definitely a bit unusual). It is unusual. Not necessarily bad, but it will require more explanation and attention because of the confusion it would cause. Also, what do we mark JIRA entries with for "fix version"? If we don't know the time a next release will come, it's hard to mark the next release, and our current odd-even won't work any longer either. It's important to be able to tell when a bug was fixed. -Steve
