cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <jburw...@basho.com>
Subject Re: In-Development Release Naming
Date Tue, 02 Jul 2013 14:00:42 GMT
Sudha,

I think it would make tickets easier to comprehend for the casual project contributor/follower.
 Additionally, the reality is that all tickets don't get closed during the development cycle.
 As I think through it, changing the JIRA release name when cut the branch to "x.y.z (codename)"
would make things easier to follow through the entire development cycle and ensure no tickets
carried over from the development cycle don't get lost in the cracks.  Does that make sense?

Thanks,
-John

On Jul 2, 2013, at 9:47 AM, Sudha Ponnaganti <sudha.ponnaganti@citrix.com> wrote:

> Yes - it can be changed in JIRA unless some workflow is set up not to do that in ACS.

> However I think we can leave the defects logged before release with codename. I do not
see a reason that they should be moved to version number post GA. 
> 
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com] 
> Sent: Tuesday, July 02, 2013 6:27 AM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
> 
> Sudha,
> 
> In JIRA, is it possible to change an exist release name?  If so, we use the code name
until the release is cut, and change the JIRA release name to x.y.z (codename) which would
make tracking consistent throughout the cycle.  Otherwise, as part of the branch creation
process, we could create a new release name as x.y.z (codename) and move all tickets with
the codename release name to the new release and remove the codename release from JIRA.
> 
> Thanks,
> -John
> 
> On Jul 2, 2013, at 9:24 AM, Sudha Ponnaganti <sudha.ponnaganti@citrix.com> wrote:
> 
>> +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:jburwell@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 <runseb@gmail.com> wrote:
>> 
>>> On 7/2/13 10:22 AM, Daan Hoogland wrote:
>>>> On Tue, Jul 2, 2013 at 10:02 AM, Sebastien Goasguen<runseb@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,
>>>> 
>>>> 
>>> 
>> 
> 


Mime
View raw message