Version might be a good idea. Version also has onOrAfter (compare) method, which if we'll use for SI.getVersion, will make StringHelper.versionComparator moot?
Today we write a String (x.y) as the segment's version. We can add methods to Version to (de)serialize itself from/to that String. Are you proposing we change SI.getVersion to return Version instead of String? Are we allowed to do that (on 3x)? We can deprecate it and add getCodeVersion (or some other name). Then, Constants.LUCENE_MAIN_VERSION can point to the latest Version, instead of a fixed string. Shai On Mon, May 23, 2011 at 6:49 PM, Michael McCandless < [email protected]> wrote: > We also have Version.LUCENE_XX, which we declare for all versions that > were needed for back compat somewhere (I think)? Can we somehow match > up SegmentInfo.getVersion to those constants? > > Mike > > http://blog.mikemccandless.com > > On Mon, May 23, 2011 at 11:10 AM, Shai Erera <[email protected]> wrote: > > Hi > > > > Today, that class declares only one field LUCENE_MAIN_VERSION, which is > > changed between releases. When 3.1 was released, it was set to "3.1" and > now > > it is set to "3.2". > > > > I think that it will be good if we have a constants per version that can > be > > found in a SegmentInfo.getVersion(), so that we can easily compare a > certain > > SI.getVersion() w/ some release. We already have the following versions: > > "2.x" - for any pre-3.0 indexes > > "3.0" > > "3.1" > > "3.2" (in 3x, unreleased) > > "4.0" (in trunk, unreleased) > > > > This will be useful for LUCENE-2921 as well. > > > > Shai > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
