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 Mon, 15 Jul 2013 20:39:07 GMT
Sudha,

My thought is that when we identify the codename for a release, we would add it to JIRA (e.g.
Gamma Rays).  All defects found before pre-freeze for that release would use this version
label.  When we cut the release branch and determine the actual version number of the release
(e.g. 4.3.0), we change the release label from <code name> (e.g. Gamma Rays) to <version
number> (<code name>) (e.g. 4.3.0 (Gamma Rays)).  As I understand JIRA, we can change
this label without disturbing existing tickets (i.e. they will go from displaying "Gamma Rays"
to "4.3.0 (Gamma Rays)" for all tickets associated with the label).  Is my understanding correct?
 If so, is my explanation making sense?

Thanks(for your patience with hand-fisted explaination), 
-John

On Jul 15, 2013, at 4:34 PM, Sudha Ponnaganti <sudha.ponnaganti@citrix.com> wrote:

> Do you mean pre- release defects would retain code name  and Post release defects would
have a codename + release version??
> 
> 
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com] 
> Sent: Monday, July 15, 2013 1:17 PM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
> 
> Sudha,
> 
> Sorry, let this discussion fall off the bottom of my inbox.  I am assuming that folks
only set the "Affected Version/s" field when creating defects.  To my mind, we should only
be setting the "Fixed Version/s" field when we are closing a defect.  If we following this
behavior, why would any tickets need to be modified as part of the release process?  Once
we know to which version number a code name will resolve (i.e. when we cut the release branch
@ code freeze), it seems wise to add that information to the version label to assist defect
reporters.  Does that make sense?
> 
> Thanks,
> -John
> 
> On Jul 2, 2013, at 11:16 AM, Sudha Ponnaganti <sudha.ponnaganti@citrix.com> wrote:
> 
>> I definitely understand the easy aspect to carry over defects to version number for
committers and contributors.  But we should triage them and move them to future or next release
and  get ready for GA. That is one of GA readiness tasks. Below is simple workflow to explain
the reason what I am referring to. 
>> 
>> - Codename gets created in defect tracking tool for release and dev 
>> cycles happen
>> - Code is hardened and ready to be released
>> - Release version is decided and set in defect tracking tool
>> - All GA readiness activities take place - Progressive defect triage 
>> is one of the aspects that come to a closure including deferrals/ 0 in 
>> dev and 0 in qa defects ( in ACS we do this steps a little differently 
>> now)
>> - GA is achieved
>> - Post GA defects logged against release version
>> 
>> Data from pre and post release metrics is fed in to initiatives that we take up for
overall improvement of quality goals for product.  I would think many of the members from
community are familiar with this model. But for operationally if this is easy for us to move
defects I am fine with it. 
>> 
>> 
>> -----Original Message-----
>> From: John Burwell [mailto:jburwell@basho.com]
>> Sent: Tuesday, July 02, 2013 7:01 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: In-Development Release Naming
>> 
>> 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