lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Solr version housekeeping in Jira/Wiki (1.5, 1.6, 3.x, 4.x, etc...)
Date Thu, 27 May 2010 21:42:13 GMT

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 <>
: Reply-To:
: To: Lucene Dev <>
: 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...
: 	...against the official 1.4 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...
: 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...
: ...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:
: For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message