[
https://issues.apache.org/jira/browse/LUCENE-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053814#comment-13053814
]
Michael McCandless commented on LUCENE-3226:
--------------------------------------------
bq. What is the benefit of naming the constant according to what has changed?
Because then devs trying to work w/ the code have some sense of what the change
was? EG for debugging maybe it's helpful, eg if something has gone wrong,
later, in how SegmentInfos is handling that version or what not.
bq. And what if two changes occur in the same release?
Well, we can handle that case by case? I agree it's messy... maybe pick a name
describing/subsuming both? Or favor one name (maybe the "bigger change") and
use comments to explain the other change?
But if there is a comment/comments above the constant containing this same
information that's just as good...
bq. These constants, IMO, are used only to detect code that is needed to
support a certain version, and nothing more.
Right, but for the devs that need to revisit such code, it's helpful to know
what "real" change occurred within that version... else, during debugging
they'd have to eg go do some svn archaeology to understand the change.
bq. And since the purpose of LUCENE-2921 is to move all index format tracking
to be at the 'code'-level and not 'feature'-level, I'd assume the constants
would be named accordingly.
True... so maybe we take this up under that issue? I would be OK with just
having comments that describe what changed in each version...
So for this issue maybe re-commit just the CheckIndex fix, and leave the
constant naming fixes to LUCENE-2921?
> rename SegmentInfos.FORMAT_3_1 and improve description in CheckIndex
> --------------------------------------------------------------------
>
> Key: LUCENE-3226
> URL: https://issues.apache.org/jira/browse/LUCENE-3226
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 3.1, 3.2
> Reporter: Hoss Man
> Fix For: 3.3, 4.0
>
> Attachments: LUCENE-3226.patch
>
>
> A 3.2 user recently asked if something was wrong because CheckIndex was
> reporting his (newly built) index version as...
> {noformat}
> Segments file=segments_or numSegments=1 version=FORMAT_3_1 [Lucene 3.1]
> {noformat}
> It seems like there are two very confusing pieces of information here...
> 1) the variable name of SegmentInfos.FORMAT_3_1 seems like poor choice. All
> other FORMAT_* constants in SegmentInfos are descriptive of the actual change
> made, and not specific to the version when they were introduced.
> 2) whatever the name of the FORMAT_* variable, CheckIndex is labeling it
> "Lucene 3.1", which is missleading since that format is alwasy used in 3.2
> (and probably 3.3, etc...).
> I suggest:
> a) rename FORMAT_3_1 to something like "FORMAT_SEGMENT_RECORDS_VERSION"
> b) change CheckIndex so that the label for the "newest" format always ends
> with " and later" (ie: "Lucene 3.1 and later") so when we release versions
> w/o a format change we don't have to remember to manual list them in
> CheckIndex. when we *do* make format changes and update CheckIndex " and
> later" can be replaced with " to X.Y" and the new format can be added
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
