if this is how jira works I would like to put the ugly +1 to that. If we don't go for code names we can still work like that by using a new label 'master' all the time and renaming that one before creating a new one. As I said, I like the code naming principle.
regards, On Mon, Jul 15, 2013 at 10:39 PM, John Burwell <jburw...@basho.com> wrote: > 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.ponnaga...@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: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, > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > >
