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
