Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Mon, 2 May 2011 16:58:34 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: dev@lucene.apache.org
Subject: Re: jira issues falling off the radar -- "Next" JIRA version
In-Reply-To: <1304262186778-2886427.post@n3.nabble.com>
Message-ID: <alpine.DEB.2.00.1105021654150.28424@bester>
References: <1304262186778-2886427.post@n3.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: and substitute either 3.2 or 4.0.  Speaking of which, I think simply
: assigning a fix-version for "3.2" implies that it will be for any future
: release (including 4.0) and so I don't see there's a point in assigning both
: of these fix-versions.  There are rare exceptions to this and I am aware of
: course that our dual-development branches implies having to make two
: commits.

No ... that's not really true at all:  A bug might only exist on the 3x 
branch, in which case saying the fix was commited for the 3.2 release 
doesn't say anything about 4x releases at all; A bug might exist in 3.1 
and 4.0 but require completley different patches to fix it;  Once 4.0 
comes out, it will be entirely possible for a feature to be commited to 4x 
and backported to 3x such that it's in release 4.6 and 3.10 but does not 
exist in 4.0-4.5; etc....

I think it's definitley important to track exactly what version on *every* 
branch an issue is commited in.


-Hoss

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org