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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
