Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 25 May 2010 11:34:25 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: Lucene Dev <dev@lucene.apache.org>
Subject: Solr version housekeeping in Jira/Wiki (1.5, 1.6, 3.x, 4.x,
 etc...)
Message-ID: <alpine.DEB.1.10.1005251052040.24672@radix.cryptio.net>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII


A while back, after the trunk merge (but before the 3x branch fork) yonik 
and i spear-headed a healthy depate on the list about whether the next 
version of Solr should have a lock-step version number with Lucene ... 
while i've generally come arround to yonik's way of thinking, that's *not* 
what this thread is about (i say that up front in the hopes of preventing 
this thread from devolving into a continued debate about internal vs 
marketing version numbers)

Independent of the questions of what branch the next version of SOlr 
should be released on, or what version number "label" it should be called, 
is the issue of keeping straight what bug fixes and features have been 
added to what branches.  Several issues in Jira were marked as "Fixed" in 
1.5, prior to the trunk merge but with the ambiguity about how the 
versioning was going to evlove, were never bulk updated to indicate that 
they were actaully going be fixed in 3.1 (or 4.0).  Now that we may (or 
may not) ever have a 1.5 release, it can be hard to look at a Jira issue 
and make sense of where the chnages were actually commited.  This has been 
componded by some committers (i take responsibility for being the majority 
of the problem) continuing to mark issues they commit as being fixed in 
"1.5" even though they commited to the "trunk" (after the lucene/solr 
trunk merge)

Likewise for the way we annotate information in the Solr wiki.  Several 
bits of documentation are annoated as being in 1.5, but nothing is marked 
as 3.1 or 4.1

What i'd like to propose is that we focus on making sure the 
"Fix Version" in Jira and the annotations on the wiki correctly reflect 
the "next" version of the *branches* where changes have been commited. 
Even if (in the unlikely event) the final version numbers that we 
release are ultimatley differnet, we can at least be reasonably confident 
that a simple batch replace will work.

In concrete terms, these are the steps i'm planning to take in a few days 
unless someone objects, or suggests a simpler path...

1) create a new Jira version for Solr called "next" as a way to track 
unresolved issues that people generally feel should be fixed in the "next" 
feature release.

2) bulk change any Solr issue currently UNRESOLVED with a "Fix Version" or 
1.5, 1.6, 3.1, or 4.0 so that it's new Fix Version is "next"

3) Compute three diffs, one for each of each of these three 
CHANGES.txt files...

http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.5-dev/CHANGES.txt
http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/solr/CHANGES.txt
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt
 	...against the official 1.4 CHANGES.txt...
http://svn.apache.org/viewvc/lucene/solr/tags/release-1.4.0/CHANGES.txt

4) merge the diffs from step#3 into a 4 column report, listing every issue 
mentioned in any of those three CHANGES.txt files and which "branches" it 
has been commited to.

5) using the report for step#4, manually update every individual issue so 
that the Fix Version accurately the list of *possible* versions that issue 
will be fixed in, if there is a release off of those respective branches 
(ie: some subset of (1.5, 3.1, 4.0))

6) delete "1.6" as a Solr version in Jira.

7) Update the Solr1.5 wiki page to link to the 1.5 branch in SVN, and add 
a note that such a release may never actually happen... 
http://wiki.apache.org/solr/Solr1.5

8) Create new wiki pages for Solr3.1 and Solr4.0, model them after the 
Solr1.5 page with pointers to what branch of SVN development is taking 
place on and where to track issues fixed on those branches.  (we can also 
add verbage here about the merged lucene/solr dev model, and why the 3x 
branch was created, but we can worry about that later)

9) Audit every link to the Solr1.5 page, and add links to the new Solr3.1 
and Solr4.0 pages as needed...
http://wiki.apache.org/solr/Solr1.5?action=fullsearch&context=180&value=linkto%3A%22Solr1.5%22


...I'm not particularly looking forward to step #5, but it's the only safe 
way i can thin of to make everything is correct.  I'm open to other 
suggestions.


-Hoss


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