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:jburw...@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.ponnaga...@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:jburw...@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.ponnaga...@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:jburw...@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.ponnaga...@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: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, >>>>> >>>>> >>>> >>> >> >
