[prev in list] [next in list] [prev in thread] [next in thread]
List: openmrs-dev
Subject: Re: When to use release version in JIRA
From: Burke Mamlin <burke () openmrs ! org>
Date: 2013-02-28 18:58:05
Message-ID: CAKgo1ZYcoUVHUMz6S+LBsSXnpD1BdUhH1iH=NhPZJ=w8+g5kvA () mail ! gmail ! com
[Download RAW message or body]
Looking at a list of Atlassian
issues<https://jira.atlassian.com/issues/?jql=resolution%20%3D%20unresolved%20AND%20fixVersion%20is%20not%20EMPTY%20AND%20project%20%3D%20conf>
(click
any one and browse up/down the list with J & K), it appears that they've
addressed this issue by creating milestones like
4.3.x-Backlog<https://jira.atlassian.com/browse/CONF-27140>.
That might be the ticket (pun intended) – i.e., when you think something
should get done in version 1.10, you assign it to the 1.10.x-Backlog
milestone and only when it's fixed or at least scheduled for work (that is
just about to happen… like for a Sprint), would it move to 1.10 or 1.10.2.
-Burke
On Thu, Feb 28, 2013 at 11:12 AM, Mark Goodrich <mgoodrich@pih.org> wrote:
> Yeah, I'm leaning back towards saying we just use fixVersion = intended
> fix version
>
>
> On 02/28/2013 11:06 AM, Darius Jazayeri wrote:
>
> Do note that Jira seems to be built around having fix version be the
> intended fix version...
>
> -Darius (by phone)
> On Feb 28, 2013 7:39 AM, "Burke Mamlin" <burke@openmrs.org> wrote:
>
> > I think fixVersion is better used as an indication of the version(s)
> > within which the issue was actually fixed – i.e., set at the time that code
> > is committed.
> >
> > I would prefer to find another place or method for tracking our
> > intentional milestons, since these a prone to change. It seems that an
> > approach where milestones define their tickets rather than vice versa would
> > be better.
> >
> > -Burke
> >
> >
> > On Thu, Feb 28, 2013 at 9:56 AM, Rafal Korytkowski <rafal@openmrs.org>wrote:
> >
> > > Mike, I'm still having trouble understanding. Whenever I do a backport,
> > > I do it for all fixVersions. The ticket must not be closed before all
> > > backports are done.
> > >
> > > If code is committed only to 1.10 and you want to release 1.9.3, but
> > > don't want to do all backports, you just bump 1.9.3 to 1.9.4 (it's done
> > > automatically by JIRA when releasing 1.9.3).
> > >
> > > If you really want a fix in 1.9.3, but don't have time to do all other
> > > backports, I would just create a separate ticket for backporting other
> > > versions and close the original one.
> > >
> > >
> > > -Rafał
> > >
> > >
> > > On 28 February 2013 15:47, Rowan Seymour <rowanseymour@gmail.com> wrote:
> > >
> > > > What about using sub-tasks for each required backport or would that be
> > > > tedious ?
> > > >
> > > >
> > > > On 28 February 2013 16:36, Michael Seaton <mseaton@pih.org> wrote:
> > > >
> > > > > I think this could work fine if all backporting is done at the time
> > > > > the original fix is committed, but this doesn't seem like common practice.
> > > > > So you end up with a ticket that is in "Code Review Post-Commit", with fix
> > > > > versions of 1.7.5, 1.8.4, 1.9.4, 1.10 , but for which code has only been
> > > > > committed to the 1.10 branch.
> > > > >
> > > > > It makes a lot more sense to me to have one field that indicates the
> > > > > places where the problem exists _and_ we desire to fix it (and this is what
> > > > > I'm suggesting we adopt "Affects Version" to be), and then another field
> > > > > that indicates where the fix has already been applied in the code (which is
> > > > > what I think fix version should be).
> > > > >
> > > > > This will allow us to keep track of what tickets people desire to have
> > > > > backported, and to what versions, and whether or not that backporting has
> > > > > been done or not, before we approve and close a ticket.
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > >
> > > > > On 02/28/2013 01:10 AM, Rowan Seymour wrote:
> > > > >
> > > > > What actually is the problem with using fix version for both "should
> > > > > fix for" and "was fixed for" as we currently do? As Rafal mentioned, JIRA
> > > > > should automatically be able to automatically update the "fix version" for
> > > > > issues that weren't resolved in the release you're making.
> > > > >
> > > > > Labels won't automatically update and won't be synced with the list
> > > > > of releases
> > > > >
> > > > > -Rowan
> > > > >
> > > > > On 28 February 2013 00:48, Mark Goodrich <mgoodrich@pih.org> wrote:
> > > > >
> > > > > > Using labels probably makes the most sense, as long as we can do it
> > > > > > in a way to make it easy for people to remember to do it. Earlier this
> > > > > > week I needed to do a query that said "get me all the tickets that are
> > > > > > supposed to be in 1.9.3 that have not yet been resolved", and we will \
> > > > > > lose this if we have a stricter definition of what fixed version is (and \
> > > > > > don't come up with a replacement).
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 02/27/2013 10:47 AM, Michael Downey wrote:
> > > > > >
> > > > > > Mark,
> > > > > >
> > > > > > On Wed, Feb 27, 2013 at 10:47 AM, Mark Goodrich <mgoodrich@pih.org[image:
> > > > > > Look up in Salesforce]> wrote:
> > > > > >
> > > > > > > I think your logic makes sense... It may be that we are using fix
> > > > > > > version in lieu of having a way of marking that a fix *should* be
> > > > > > > backported to 1.9.x. Anyone know of the preferred way to note this?
> > > > > > >
> > > > > >
> > > > > > The other easy approach rather than using fixVersion would be using
> > > > > > labels.
> > > > > >
> > > > > > Michael
> > > > > > --
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Michael Downey
> > > > > > OpenMRS Community Infrastructure Team
> > > > > > michael@openmrs.org[image: Look up in Salesforce] -
> > > > > > http://openmrs.org/
> > > > > > --
> > > > > > OpenMRS Developers: http://go.openmrs.org/dev
> > > > > > Post: dev@openmrs.org
> > > > > > Unsubscribe: dev+unsubscribe@openmrs.org
> > > > > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > OpenMRS Developers: http://go.openmrs.org/dev
> > > > > > Post: dev@openmrs.org
> > > > > > Unsubscribe: dev+unsubscribe@openmrs.org
> > > > > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Rowan Seymour*
> > > > > tel: +250 783835665 <%2B250%20783835665>
> > > > > --
> > > > > OpenMRS Developers: http://go.openmrs.org/dev
> > > > > Post: dev@openmrs.org
> > > > > Unsubscribe: dev+unsubscribe@openmrs.org
> > > > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > OpenMRS Developers: http://go.openmrs.org/dev
> > > > > Post: dev@openmrs.org
> > > > > Unsubscribe: dev+unsubscribe@openmrs.org
> > > > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Rowan Seymour*
> > > > tel: +250 783835665 <%2B250%20783835665>
> > > > --
> > > > OpenMRS Developers: http://go.openmrs.org/dev
> > > > Post: dev@openmrs.org
> > > > Unsubscribe: dev+unsubscribe@openmrs.org
> > > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > > >
> > > >
> > > >
> > >
> > > --
> > > OpenMRS Developers: http://go.openmrs.org/dev
> > > Post: dev@openmrs.org
> > > Unsubscribe: dev+unsubscribe@openmrs.org
> > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > >
> > >
> > >
> >
> > --
> > OpenMRS Developers: http://go.openmrs.org/dev
> > Post: dev@openmrs.org
> > Unsubscribe: dev+unsubscribe@openmrs.org
> > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> >
> >
> >
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
>
>
>
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org
> Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
>
>
--
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org
Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
[Attachment #3 (text/html)]
<div dir="ltr">Looking at a <a \
href="https://jira.atlassian.com/issues/?jql=resolution%20%3D%20unresolved%20AND%20fixVersion%20is%20not%20EMPTY%20AND%20project%20%3D%20conf">list \
of Atlassian issues</a> (click any one and browse up/down the list with J & K), \
it appears that they've addressed this issue by creating milestones like <a \
href="https://jira.atlassian.com/browse/CONF-27140">4.3.x-Backlog</a>. That might \
be the ticket (pun intended) – i.e., when you think something should get done in \
version 1.10, you assign it to the 1.10.x-Backlog milestone and only when it's \
fixed or at least scheduled for work (that is just about to happen… like for a \
Sprint), would it move to 1.10 or 1.10.2.<div>
<br></div><div>-Burke<br><div class="gmail_extra"><br><br><div class="gmail_quote">On \
Thu, Feb 28, 2013 at 11:12 AM, Mark Goodrich <span dir="ltr"><<a \
href="mailto:mgoodrich@pih.org" target="_blank">mgoodrich@pih.org</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Yeah, I'm leaning back towards saying
we just use fixVersion = intended fix version<div><div><br>
<br>
On 02/28/2013 11:06 AM, Darius Jazayeri wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">
<p dir="ltr">Do note that Jira seems to be built around having fix
version be the intended fix version...</p>
<p dir="ltr">-Darius (by phone)</p>
<div class="gmail_quote">On Feb 28, 2013 7:39 AM, "Burke Mamlin"
<<a href="mailto:burke@openmrs.org" \
target="_blank">burke@openmrs.org</a>> wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div dir="ltr">I think fixVersion is better used as an
indication of the version(s) within which the issue was
actually fixed – i.e., set at the time that code is
committed.
<div><br>
</div>
<div>I would prefer to find another place or method for
tracking our intentional milestons, since these a prone to
change. It seems that an approach where milestones define
their tickets rather than vice versa would be better.</div>
<div><br>
</div>
<div>-Burke</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Feb 28, 2013 at 9:56 AM,
Rafal Korytkowski <span dir="ltr"><<a \
href="mailto:rafal@openmrs.org" target="_blank">rafal@openmrs.org</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr">Mike, I'm \
still having trouble understanding. Whenever I do a backport, I do it for
all fixVersions. The ticket must not be closed before
all backports are done.
<div>
<br>
</div>
<div>If code is committed only to 1.10 and you want to
release 1.9.3, but don't want to do all backports,
you just bump 1.9.3 to 1.9.4 (it's done
automatically by JIRA when releasing 1.9.3).
<div>
<br>
</div>
<div>If you really want a fix in 1.9.3, but don't
have time to do all other backports, I would just
create a separate ticket for backporting other
versions and close the original one.</div>
</div>
</div>
<div class="gmail_extra">
<br clear="all">
<div><br>
-Rafał</div>
<div>
<div>
<br>
<br>
<div class="gmail_quote">On 28 February 2013
15:47, Rowan Seymour <span dir="ltr"><<a \
href="mailto:rowanseymour@gmail.com" \
target="_blank">rowanseymour@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr">What about using \
sub-tasks for each required backport or would that be
tedious ?</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 28 February
2013 16:36, Michael Seaton <span dir="ltr"><<a \
href="mailto:mseaton@pih.org" target="_blank">mseaton@pih.org</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I think \
this could work fine if all backporting is
done at the time the original fix
is committed, but this doesn't
seem like common practice. So you
end up with a ticket that is in
"Code Review Post-Commit", with
fix versions of 1.7.5, 1.8.4,
1.9.4, 1.10 , but for which code
has only been committed to the
1.10 branch.<br>
<br>
It makes a lot more sense to me to
have one field that indicates the
places where the problem exists
_and_ we desire to fix it (and
this is what I'm suggesting we
adopt "Affects Version" to be),
and then another field that
indicates where the fix has
already been applied in the code
(which is what I think fix version
should be).<br>
<br>
This will allow us to keep track
of what tickets people desire to
have backported, and to what
versions, and whether or not that
backporting has been done or not,
before we approve and close a
ticket.<br>
<br>
Mike
<div>
<div><br>
<br>
<br>
<div>On 02/28/2013 01:10 AM,
Rowan Seymour wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>What actually is the
problem with using fix
version for both "should
fix for" and "was fixed
for" as we currently do?
As Rafal mentioned, JIRA
should automatically be
able to automatically
update the "fix version"
for issues that weren't
resolved in the release
you're making.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Labels
won't automatically
update and won't be
synced with the list of
releases</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">-Rowan<br>
<br>
<div class="gmail_quote">On
28 February 2013
00:48, Mark Goodrich <span \
dir="ltr"><<a href="mailto:mgoodrich@pih.org" \
target="_blank">mgoodrich@pih.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div text="#000000" \
bgcolor="#FFFFFF"> <div>Using labels
probably makes
the most sense,
as long as we
can do it in a
way to make it
easy for people
to remember to
do it. Earlier
this week I
needed to do a
query that said
"get me all the
tickets that are
supposed to be
in 1.9.3 that
have not yet
been resolved",
and we will lose
this if we have
a stricter
definition of
what fixed
version is (and
don't come up
with a
replacement).<span><font \
color="#888888"><br> <br>
Mark</font></span>
<div><br>
<br>
<br>
On 02/27/2013
10:47 AM,
Michael Downey
wrote:<br>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div \
class="gmail_extra">Mark,</div>
<div \
class="gmail_extra"><br>
<div class="gmail_quote">On
Wed, Feb 27,
2013 at 10:47
AM, Mark
Goodrich <span \
dir="ltr"><<a href="mailto:mgoodrich@pih.org" \
target="_blank">mgoodrich@pih.org</a><img alt="Look up in Salesforce" title="Look up \
in
Salesforce" width="12" \
height="12">></span> wrote:<br>
<blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div \
style="font-family:Calibri,sans-serif;font-size:11pt">I think your
logic makes
sense... It
may be that we
are using fix
version in
lieu of having
a way of
marking that a
fix *should*
be backported
to 1.9.x.
Anyone know of
the preferred
way to note
this?<br>
</div>
</blockquote>
</div>
<br>
The other easy
approach
rather than
using
fixVersion
would be using
labels.<br>
<br clear="all">
<div>Michael</div>
-- <br>
<br>
Best regards,<br>
<br>
Michael Downey<br>
OpenMRS
Community
Infrastructure
Team<br>
<a \
href="mailto:michael@openmrs.org" target="_blank">michael@openmrs.org</a><img \
alt="Look up in Salesforce" title="Look up in
Salesforce" width="12" \
height="12"> -
<a \
href="http://openmrs.org/" target="_blank">http://openmrs.org/</a> </div> </div>
-- <br>
OpenMRS
Developers: <a \
href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br> Unsubscribe: \
<a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your
OpenMRS
subscriptions
at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</blockquote>
<br>
</div>
</div>
</div>
<div>
<div> -- <br>
OpenMRS
Developers: <a \
href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br> Unsubscribe: \
<a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your
OpenMRS
subscriptions at
<a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<b>Rowan Seymour</b><br>
tel: <a href="tel:%2B250%20783835665" \
value="+250783835665" target="_blank">+250 783835665</a><br>
</div>
</div>
-- <br>
OpenMRS Developers: <a \
href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a \
href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS
subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</blockquote>
<br>
</div>
</div>
</div>
<div>
<div>
-- <br>
OpenMRS Developers: <a \
href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a \
href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS
subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<b>Rowan Seymour</b><br>
tel: <a href="tel:%2B250%20783835665" \
value="+250783835665" target="_blank">+250 783835665</a><br>
</div>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a \
href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<div>
<div>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a href="https://id.openmrs.org/" \
target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</blockquote>
</div>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br>
Manage your OpenMRS subscriptions at <a href="https://id.openmrs.org/" \
target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
</blockquote>
<br>
</div></div></div><div><div>
<p></p>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a><br>
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> \
<br> <br>
</div></div></blockquote></div><br></div></div></div>
<p></p>
-- <br />
OpenMRS Developers: <a \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br />
Post: dev@openmrs.org<br />
Unsubscribe: dev+unsubscribe@openmrs.org<br />
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/">https://id.openmrs.org/</a><br /> <br />
<br />
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic