Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of jburwell@basho.com designates
 209.85.128.41 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: In-Development Release Naming
From: John Burwell <jburwell@basho.com>
In-Reply-To: <07B22C5ED940BF49B3438A3983DB5775093971@SJCPEX01CL03.citrite.net>
Date: Mon, 15 Jul 2013 16:39:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <27930B4A-21D3-4349-9139-450592108182@basho.com>
References: <2F5E56AA-A9C9-4576-9410-0B305E9FA312@basho.com>
 <20130701201529.GQ74679@USLT-205755.sungardas.corp>
 <CAA1Nr16Q5kz1nU0hyxomVF_1eS6gM_wVg5MuS7g_s-=0GHQ-hw@mail.gmail.com>
 <CAGQtxvYUr2CAcbyb2kStoc0MV1Rk8WMo0JjX1CjECHF1CR6kXg@mail.gmail.com>
 <84C2CDB0-777A-427B-9F03-AD9ACC35AD49@gmail.com>
 <CAGQtxvb-TnJFeL4APUKukTD_CTkXrh4MtDo-GCi_kJ_jZUYjZA@mail.gmail.com>
 <51D28F5E.7030409@gmail.com> <2BFBA19B-FDF0-45CD-ABB3-1866536EF4C6@basho.com>
 <07B22C5ED940BF49B3438A3983DB577507C4B7@SJCPEX01CL03.citrite.net>
 <F1D87C1A-D0A0-4334-98BF-6988ABFBD6F5@basho.com>
 <07B22C5ED940BF49B3438A3983DB577507C58F@SJCPEX01CL03.citrite.net>
 <EF9E2017-3699-4F2A-9956-E0C9D59C2275@basho.com>
 <07B22C5ED940BF49B3438A3983DB577507C9AB@SJCPEX01CL03.citrite.net>
 <AE0B6C68-43AB-4DB5-8D45-E9208840ED95@basho.com>
 <07B22C5ED940BF49B3438A3983DB5775093971@SJCPEX01CL03.citrite.net>
To: dev@cloudstack.apache.org

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),=20
-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??
>=20
>=20
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]=20
> Sent: Monday, July 15, 2013 1:17 PM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
>=20
> Sudha,
>=20
> 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?
>=20
> Thanks,
> -John
>=20
> On Jul 2, 2013, at 11:16 AM, Sudha Ponnaganti =
<sudha.ponnaganti@citrix.com> wrote:
>=20
>> 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.=20
>>=20
>> - Codename gets created in defect tracking tool for release and dev=20=

>> 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=20=

>> is one of the aspects that come to a closure including deferrals/ 0 =
in=20
>> dev and 0 in qa defects ( in ACS we do this steps a little =
differently=20
>> now)
>> - GA is achieved
>> - Post GA defects logged against release version
>>=20
>> 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.=20
>>=20
>>=20
>> -----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
>>=20
>> Sudha,
>>=20
>> 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?
>>=20
>> Thanks,
>> -John
>>=20
>> On Jul 2, 2013, at 9:47 AM, Sudha Ponnaganti =
<sudha.ponnaganti@citrix.com> wrote:
>>=20
>>> Yes - it can be changed in JIRA unless some workflow is set up not =
to do that in ACS.=20
>>> 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.=20
>>>=20
>>> -----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
>>>=20
>>> Sudha,
>>>=20
>>> 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.
>>>=20
>>> Thanks,
>>> -John
>>>=20
>>> On Jul 2, 2013, at 9:24 AM, Sudha Ponnaganti =
<sudha.ponnaganti@citrix.com> wrote:
>>>=20
>>>> +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.=20
>>>>=20
>>>> -----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
>>>>=20
>>>> Sebastien,
>>>>=20
>>>> 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.  =46rom 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. =20
>>>>=20
>>>> Thanks,
>>>> -John
>>>>=20
>>>> On Jul 2, 2013, at 4:29 AM, Sebastien Goasguen <runseb@gmail.com> =
wrote:
>>>>=20
>>>>> 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:
>>>>>>=20
>>>>>>=20
>>>>>>> To me, codenames are confusing . I'd rather see a clear message=20=

>>>>>>> like "we are bumping the release number to version x.y because =
of=20
>>>>>>> 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."
>>>>>>>=20
>>>>>>=20
>>>>>> Sebastien, It would seem to me that '4.2 pre-rc dev release that=20=

>>>>>> may later become 5.0 but we are not sure.' is at the least not=20
>>>>>> less confusing. A 4.2 rc implies that the fact that there will be=20=

>>>>>> a 4.2 is set, which is not true if the number is bumped.
>>>>>>=20
>>>>>=20
>>>>> Right, but we should know before cutting a "4.2" branch if it's=20
>>>>> really going to be 4.2 or not, from looking at JIRA and proposed=20=

>>>>> features
>>>>>=20
>>>>>> Other then that I agree that the fun of having a gammaray release=20=

>>>>>> is rather thin as justification.
>>>>>>=20
>>>>>> regards,
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20