cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: In-Development Release Naming
Date Tue, 16 Jul 2013 20:53:42 GMT
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 <jburwell@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.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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message