+1 to use code name during dev cycles and name the version for GA release for reasons outlined by John B. When querying metrics also would help to identify which defects are logged pre release and which came in post release i.e GA.
-----Original Message----- From: John Burwell [mailto:jburw...@basho.com] Sent: Tuesday, July 02, 2013 6:13 AM To: dev@cloudstack.apache.org Subject: Re: In-Development Release Naming Sebastien, Actually, you are completely correct. When we cut a release branch, we know the scope of change and can apply of the semantic versioning rules to service the correct version number (i.e. whether to increment x, y, or z). However, we have a 4 month period of development on feature releases when we are communicating about our work, but don't yet know whether the changes will require incrementing x or y. For that period of time I am proposing that we use a code name. When we freeze, we evaluate the change and determine the version number. From that point on the release will referred to as either the codename or the release number. I think it would make sense in version strings that we display releases as x.y.z (codename) to help people correlate the development period with the eventual release number. Thanks, -John On Jul 2, 2013, at 4:29 AM, Sebastien Goasguen <run...@gmail.com> wrote: > On 7/2/13 10:22 AM, Daan Hoogland wrote: >> On Tue, Jul 2, 2013 at 10:02 AM, Sebastien Goasguen<run...@gmail.com>wrote: >> >> >>> To me, codenames are confusing . I'd rather see a clear message like >>> "we are bumping the release number to version x.y because of this >>> major feature...." than start talking about a " "gammaray" pre-RC dev >>> release that will later maybe become x.y but we are not sure." >>> >> >> Sebastien, It would seem to me that '4.2 pre-rc dev release that may >> later become 5.0 but we are not sure.' is at the least not less >> confusing. A 4.2 rc implies that the fact that there will be a 4.2 is >> set, which is not true if the number is bumped. >> > > Right, but we should know before cutting a "4.2" branch if it's really > going to be 4.2 or not, from looking at JIRA and proposed features > >> Other then that I agree that the fun of having a gammaray release is >> rather thin as justification. >> >> regards, >> >> >
