[
https://issues.apache.org/jira/browse/LUCENE-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved LUCENE-5364.
--------------------------------
Resolution: Fixed
Fix Version/s: 4.7
5.0
Assignee: Steve Rowe
Lucene Fields: New,Patch Available (was: New)
Committed to trunk and branch_4x.
I added a note to the Lucene ReleaseToDo wiki page about using
{{:Post-Release-Update-Version.LUCENE_XY:}} to find constants that should be
upgraded to the next release version after a release branch has been cut.
> Review usages of hard-coded Version constants
> ---------------------------------------------
>
> Key: LUCENE-5364
> URL: https://issues.apache.org/jira/browse/LUCENE-5364
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
> Affects Versions: 5.0, 4.7
> Reporter: Steve Rowe
> Assignee: Steve Rowe
> Priority: Minor
> Fix For: 5.0, 4.7
>
> Attachments: LUCENE-5364-branch_4x.patch, LUCENE-5364-trunk.patch,
> LUCENE-5364-trunk.patch
>
>
> There are some hard-coded {{Version.LUCENE_XY}} constants used in various
> places. Some of these are intentional and appropriate:
> * in deprecated code, e.g. {{ArabicLetterTokenizer}}, deprecated in 3.1, uses
> {{Version.LUCENE_31}}
> * to make behavior version-dependent (e.g. {{StandardTokenizer}} and other
> analysis components)
> * to test different behavior at different points in history (e.g.
> {{TestStopFilter}} to test position increments)
> But should hard-coded constants be used elsewhere?
> For those that should remain, and need to be updated with each release, there
> should be an easy way to find them.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
