[cle-release-team] JIRA Version Maintenance

Matthew Jones matthew at longsight.com
Fri Nov 30 07:53:57 PST 2012


I agree Jean-Francois, the fix versions is ambiguous. This was suggested on
this jira ticket https://jira.atlassian.com/browse/JRA-22225

The people in the core group treat the "Fix Version/s" field as being
"Actual Fix Version/s" and should only be set by a branch manager or a
developer who commits to trunk can set it as 2.10. If we notice that
someone else has used this as an "Intended Fix Version/s" then I'll remove
it and email them personally saying what the intention of this field is.
For 2.9.1, we've used a label of 291triage as the workflow for Intended Fix
Version.

A little more reading lead me to seeing that we *could* download the
translation pack, update the field "Fix Version/s" to something clearer,
upload the pack and pick it as the default (
https://translations.atlassian.com/). This would have to be done for every
JIRA upgrade though, and probably take 15-30 minutes. Perhaps this would be
worthwhile if it reduces confusion?

Additionally, rather than using the label, I we could create a custom
version picker field where we could put in "Planned Fix Version/s". It
looks like this was considered at one time and actually implemented in a
few projects (Assignments2 and Gradebook2) but never in the CLE project. I
think this is a good idea to do both of these things?


On Fri, Nov 30, 2012 at 8:59 AM, Jean-Francois Leveque <
jean-francois.leveque at upmc.fr> wrote:

> I have the feeling that there's sometimes a confusion between intended
> fix version and actual fix version in this field.
>
> I would prefer actual fix versions because they're less confusing and
> you wouldn't have to check other fields.
>
> Thanks,
> J-F
>
> On 30/11/2012 14:54, Neal Caidin wrote:
> > Okay, maybe I'll try deletes next time instead of merges and see if that
> works better. I get the sense that the fixVersion is not used consistently,
> but I'm not sure.
> >
> > Thanks,
> > Neal
> >
> > On Nov 29, 2012, at 6:57 PM, Beth Kirschner<bkirschn at umich.edu>  wrote:
> >
> >> Hi Neal,
> >>
> >>    Comments below...
> >>
> >> - Beth
> >>
> >> On Nov 27, 2012, at 2:27 PM, Neal Caidin wrote:
> >>
> >>> Summary
> >>> --------------------
> >>> Done, mostly.  All 2.9.0 alpha, beta, and rc versions merged into
> 2.9.0 and some cleanup per Matt's cleanup list (see below).
> >>>
> >>>
> >>> Notes
> >>> ---------------
> >>>             * Side affect of merge is that there are over 800 issues
> for which at least one affectedVersion is 2.9.0 and at least one fixVersion
> is 2.9.0. Query : affectedVersion = "2.9.0" and fixVersion = "2.9.0"
> >>>             * Only affected SAK, SAM, and KNL .
> >>>             * wrt Resolved/Open/Awaiting issues having fix version
> unset,I may check with the Samigo team because they may be using the
> fixVersion in a slightly different way than the CLE release team overall.
> >>>
> >>> Questions
> >>> -----------------
> >>>             * I don't see a way to bulk change the fixVersion in Jira.
> For those Jira admins out there, am I missing something? Many fields
> showed, but not fixVersion.
> >> If you delete a version, JIRA will offer you the option to bulk change
> all open JIRAs with an affectedVersion or fixVersion set to the soon to be
> deleted version. You're given the option of changing the version or leaving
> it blank. These are two separate questions, so you can change the
> affectedVersion to 2.9.0, and change the fixedVersion to nothing (which is
> what I'd suggest).
> >>
> >>>             * Is it preferable to have an empty fixVersion or "2.10
> [tentative]" ?  There are some issues that I'm hoping we will get into
> 2.9.2, and setting to "2.10 [tentative]" fix version seems wrong. On the
> other hand, we are only setting the fixVersion for the version in which the
> Jira is actually fixed, but maybe "2.10 [tentative] is a good place holder?
> >>>
> >> I think it's preferable to have an empty fixVersion -- we generally
> don't fill in that field until it's actually fixed. That makes querying
> easier, and it's also one less thing to change (and change again) as
> releases move forward.
> >>
> >>> Thanks,
> >>>
> >>>
> >>> Neal Caidin
> >>>
> >>> Sakai CLE Community Coordinator
> >>> nealcaidin at sakaifoundation.org
> >>> Skype: nealkdin
> >>> AIM: ncaidin at aol.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Nov 19, 2012, at 4:15 PM, Matthew Jones<matthew at longsight.com>
>  wrote:
> >>>
> >>>> I'm good with this.
> >>>>
> >>>> Cleaning up the intermediary tags was also something I kept up on in
> the past:
> >>>>
> >>>> - All Verified or Resolved issues that *were* merged should be closed
> >>>> - All Resolved issues that were not merged (often because they
> weren't verified) should either be moved to the next release or have the
> fix version unset
> >>>> - All Open or Awaiting review issues should either have the fix
> version unset or moved to the next version
> >>>>
> >>>> Essentially the final release should just be all closed issues, so
> this is a decent amount of cleanup effort.
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Nov 19, 2012 at 4:04 PM, Beth Kirschner<bkirschn at umich.edu>
>  wrote:
> >>>> Hi Neal,
> >>>>
> >>>>    One thing that Anthony has done in the past, following a release,
> was to remove all the JIRA alpha, beta&  release-candidate tags, and
> consolidate them into one 2.9.0 release. When you delete a version in JIRA,
> it offers you the option to change the deleted version to another version
> (e.g. 2.9.0). I think we should continue doing this so that the version
> list is less cluttered. Let me know if you'd like some off-line help on how
> to do this. Does anyone else think we should _not_ continue with this
> practice?
> >>>>
> >>>> - Beth
> >>>> _______________________________________________
> >>>> cle-release-team mailing list
> >>>> cle-release-team at collab.sakaiproject.org
> >>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >>>>
> >>>
> >>> _______________________________________________
> >>> cle-release-team mailing list
> >>> cle-release-team at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >>
> >
> > _______________________________________________
> > cle-release-team mailing list
> > cle-release-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
> --
> Jean-François Lévêque
> Responsable technique Sakai
> Université Pierre et Marie Curie
>
> --
> Jean-Francois Leveque
> University Pierre and Marie Curie
> France
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121130/f0346a84/attachment-0006.html 


More information about the cle-release-team mailing list