On Tue, 5 Jan 2010, Chris Hostetter wrote:

: https://issues.apache.org/jira/browse/LUCENENET-331).  This begs the
: question, if Lucene.Net takes just this one patch, than Lucene.Net 2.9.1 is
: now 2.9.1.1 (which I personally don't like to see happening as I prefer to
: see a 1-to-1 release match).

As a general comment on this topic: I would suggest that if the goal of
Lucene.Net is to be a 1-to-1 port (which seems like a good goal, but
is certainly not mandatory if the Lucene.Net community has other
ambitions) then the cleanest thing for users would be to keep the version
numbers in sync 1-to-1.

it reasises some questions about what to do if a bug is discovered in the
*porting*.  ie: if after "Lucene.Net 2.9.2" is released, it's discovered
that there was a glitch, and it doesn't actually match the behavior of
Lucene-JAva 2.9.2" what should be done? ... "Lucene.Net 2.9.3" and
"Lucene.Net 2.9.2.1" could all concivably conflict with version numbers
Lucene-Java *might* someday release.

Having an anotaiton strategy that doesn't extend the dot notation
used by Lucene-Java might make sense (ie: "Lucene.Net 2.9.2-a"

Indeed, this is the approach taken by PyLucene: using the Lucene Java release number it was built from and adding a dash followed by a single number. For example, PyLucene 3.0.0-1 is the current release matching Lucene Java's 3.0.0 release. If a PyLucene-specific bug were found, it would likely be fixed in a PyLucene 3.0.0-2 release unless it coincided with a Lucene Java 3.0.1 release.

Andi..

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

Reply via email to