On Tue, Jan 20, 2015 at 10:57 AM, Steve Huston <shus...@riverace.com> wrote:
> 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. > This is a good point. The JIRA workflow I've used for proton to date has somewhat depended on being able to predict the next release number given the current release number. I would argue that's a nice property to have for version numbers in general, e.g. being able to say things like "next version" and "prior version" and have that map to something obvious relative to the current version is I think a generally user friendly thing to do. --Rafael
