FYI: I'm going to start working on this today, but i don't expect i'll finish it all in one go, so i'll reply to this message with incremental updates as i finish things and use the thread as an audit log.
: Date: Tue, 25 May 2010 11:34:25 -0700 (PDT) : From: Chris Hostetter <hossman_luc...@fucit.org> : Reply-To: dev@lucene.apache.org : To: Lucene Dev <dev@lucene.apache.org> : Subject: Solr version housekeeping in Jira/Wiki (1.5, 1.6, 3.x, 4.x, etc...) : : : 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 : -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
