On 6/21/11 6:19 AM, Kristian Waagan wrote:
On 21.06.11 14:44, Rick Hillegas wrote:
On 6/20/11 1:04 PM, Myrna van Lunteren wrote:
On Mon, Jun 20, 2011 at 12:23 PM, Rick Hillegas
<[email protected]> wrote:
On 6/20/11 11:52 AM, Myrna van Lunteren wrote:
Hi,
Can one of those with sufficient karma add 10.8.2.0 to the list of
releases in JIRA?
Thanks,
Myrna
Hi Myrna,
What would the new release number be used for? Is there any difference
between 10.8.2.0 and the current head-of-branch marker (10.8.1.4)?
Thanks,
-Rick
This would be for the bug fix release planned for September. We
typically increase the 3rd digit for those, I thought.
Right now, I only wanted to assign placeholder task for it...there's
no difference yet between top of the 10.8 branch.
D'you think we should hold off creating this version # because it
might be confusing?
People may be a little puzzled about when to use 10.8.1.4 vs. when to
use 10.8.2.0, particularly for the "fixed in" field. My inclination
would be to not create a 10.8.2.0 release id at this time. Instead, you
can rename 10.8.1.4 to be 10.8.2.0 just before you create the first RC.
+1 from a bug reporting perspective, especially since JIRA provides a
way to easily handle this (rename/merge).
The downside may be that it is harder to mark something as "due" for
the future maintenance release, but I don't think we have been doing
that a lot (?).
Although not a big deal, maybe filters are affected too?
(i.e. the RM must currently use version 10.8.1.4, but when 10.8.2.0 is
created the filters must be updated?)
I'm comfortable with draft release notes which say 10.8.1.4. The switch
to 10.8.2.0 can happen just before the RC is built.
Thanks,
-Rick
