Yes, the goal is to be 1-to-1 in sync which is how it always has been and
why version number consistency is important.

A Lucene.Net assembly, has version number with 4 digits, like so:
"Lucene.Net 2.9.1.016" -- the last number "016" is used to both signify an
internal release, as the port is progressing, and bug fix specific to
porting issues.

In this case, my question was about porting over only 1 patch from Lucene
Java 2.9.2 to Lucene.Net 2.9.1 (i.e.: a patch found in newer version of
Lucene Java to an older version of Lucene.Net).  If we do so, (which I'm
against the idea and over at Lucene.Net we decided not to do so) than this
can lead to version confusion if not well documented and possibly introduce
behavior differences (based on what the 1 ported patch ends up fixing).  Not
only this, as you pointed out, what if Lucene Java 2.9.3 comes up, than
what?
 
-- George

-----Original Message-----
From: Chris Hostetter [mailto:hossman_luc...@fucit.org] 
Sent: Tuesday, January 05, 2010 3:52 PM
To: java-dev@lucene.apache.org
Subject: Re: Lucene Java 2.9.2


: 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"


-Hoss


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


---------------------------------------------------------------------
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