db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Bumping the fourth digit
Date Wed, 18 Feb 2009 16:58:20 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> Hi Andrew,
>
> Can you help me understand why we need to add 2 new versions to JIRA
> and not just 1? One of the versions means "the next official release
> on this branch". I understand what to do with that release id: I put
> it in the "fixed in" field.
>
> But I don't understand what to do with the other version. Does the
> other version mean "the next (unofficial) patch distribution on this
> branch"? Is this release id meant to go in the "affects version"
> field? There has been some discomfort expressed on this email thread
> about using the JIRA fields to hold the release ids of distributions
> which were created outside the community.

Hi Rick,

My understanding is actually the opposite: 10.3.4.0 refers to the next
official release and should not be used for the "fixed in" field for the
fixes that we have committed. (At one point we may have used it to say
"it is my intention to fix this bug for that release", but that's not so
common anymore.)

10.3.3.1 refers to the current state of the 10.3 branch and should be
used in the "fixed in" field for fixes merged to that branch. It should
also be used in "affects version" if it is a bug introduced on the 10.3
branch after the release of 10.3.3.0 (aka regression).

I think it would be less confusing if we didn't add version numbers to
JIRA until we have a branch where sysinfo reports that version
number. Apart from adding confusion as to which number to use in reports
and what the numbers actually mean, having many unreleased version
numbers also causes JIRA usability issues like DERBY-4058.

-- 
Knut Anders

Mime
View raw message