inline-->
2005/11/22, Sean Schofield <[EMAIL PROTECTED]>:
> Here is my take ... We all agree on the meaning of the "affects
> version" field meaning the version reported against. So there always
> needs to be a "Nightly" version to reflect problems with the lastest
> and greatest source code.
>
> The "fix version" field has traditionally been used (by MyFaces) to
> mark the version the bug was *actually* fixed in. So historically we
> have been marking things fixed as nightly and then right when we
> release (or at the point of a branch) we change nightly to the next
> version number and add a new "nightly" version.
What if someone reported with "affects [Nightly]". If we rename
"Nightly" to "1.1.x" on releasing, the issue would now have the
property "affects 1.1.x", which is wrong. Because the bug was actually
FIXED in 1.1.x.
> The release notes are also built of this scheduled version so IMO its
> important to have the stuff marked as version x to be only what's
> actually fixed in that version. In theory you could change the ones
> you don't fix back to "nightly" if they don't get fixed but that is a
> *tedious* process that generates a lot of spurious emails. (I'm
> looking at setting up a custom email notification scheme for our
> project btw that might cut down on some of this.)
>
> I think it would be good to have a free text field for "scheduled to
> be fixed: " and have it be editable only by committers. We can then
> create custom filters and reports in JIRA that essentially do what
> Howard is trying to do here. Ultimately I think 3 fields are
> required: reported, scheduled and actual. Since we are already using
> the field in question for "actual" I think the new field should be
> used for scheduled.
Quick glance over Jira administration shows, that adding a custom
field should not be too difficult. Well, the road map feature only
works with the "Fix Version/s" field. So an additional "Scheduled for"
field would not help us with the road map, right?
Just had an offline discussions with Martin. In our opinion there is
no need for a "scheduled for" field if we also take the Status and
Resolution into account.
This is our conclusion:
There are actually two issues:
1. Correct use of "Affects Version"
2. Correct use of "Fix Version"
ad 1.
To actually reflect reality, there should not only be one "Nightly"
version. We should better think of "Nightly - between 1.1.1 and 1.1.2"
and see it as a released version rather than "unreleased".
Why? If we use "Nightly" as a placeholder for the upcoming release,
nobody should ever be allowed to use it as the "Affects" value,
because otherwise renaming the version would have the sideeffect that
I have mentioned above. Actually, in the "Affects Version" box,
"Nightly" shows up under "Unreleased versions", which is confusing. We
should interpret the meaning of released vs. unreleased version in
Jira as "future" vs. "published" rather than "officially released" vs.
"nightly".
How can we solve this?
Let's have more than one "Nightly" version over the time. Whenever we
release a new official version, we also add a new "Nightly" version.
To make it easy understandable for the reporter, we give each
"Nightly" version a unique name: e.g. "Nightly - after 1.1.1"
ad 2.
It should be possible to add any future versions - and perhaps even
give it a schedule date. Why not add a "1.2.0" version now with future
schedule date, for instance?
And why not have a "1.1.2" version right now?
The rule of thumb for the resolving developer would be: Never use a
"Nightly" version as "Fix Version". If we fix something, we select the
next upcoming official release version. ie. "1.1.2" by now.
This way we could even add issues for 1.2 development. "Fix version"
would be "1.2". And if we are high-spirited we even give "1.2" a
schedule date. ;-)
Our road-map would be perfect this way and Howard will love all of us, right?
Now, what would be the actions to be taken for the next release 1.1.2 ?
- Filter all issues with "Fix version" 1.1.2 that are unresolved and
alter them to 1.1.3
- Set version 1.1.2 to "released"
- Add a new version "Nightly - after 1.1.2" and also set it to
"released". Why? Because by the next day someone already might have
downloaded a new nightly and wants to report something for it.
- The release notes will be perfect. Athough not having double checked
this, I believe that Jira only adds resolved issues to the notes for a
certain release. It even does not matter because we have already
postponed the open issues to 1.1.3
Can all questions be answered with this scheme?
Q: "Is bug xy that I have reported for [Nightly-after 1.1.1] already fixed?"
A: "Browse issue, see if it has been resolved already. If resolved,
look at the date and get a suitable nightly!"
Q: "When will the bug xy be fixed?"
A: "Look at the road map!"
Q: "Which unofficial nightly version bug xy was reported for?"
A: "Browse issue. See "Affects Version" field!"
- And if you are lucky it says "Nightly - after 1.1.1" rather
than "Nightly" ;-)
Thoughts?
Manfred
