[
https://issues.apache.org/jira/browse/LUCENE-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829569#action_12829569
]
Simon Willnauer commented on LUCENE-2248:
-----------------------------------------
Uwe, as I already said while we where discussion this, I would add the version
to LuceneTestCase (or equivalent for JU4) and then we can do the tests in
sub-issues which prevents those super huge patches.
thoughts?!
> Tests using Version.LUCENE_CURRENT will produce problems in backwards branch,
> when development for 3.2 starts
> -------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2248
> URL: https://issues.apache.org/jira/browse/LUCENE-2248
> Project: Lucene - Java
> Issue Type: Test
> Components: Analysis, contrib/*, contrib/analyzers,
> contrib/benchmark, contrib/highlighter, contrib/spatial,
> contrib/spellchecker, contrib/wikipedia, Index, Javadocs, Other,
> Query/Scoring, QueryParser, Search, Store, Term Vectors
> Reporter: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
>
> A lot of tests for the most-recent functionality in Lucene use
> Version.LUCENE_CURRENT, which is fine in trunk, as we use the most recent
> version without hassle and changing this in later versions.
> The problem is, if we copy these tests to backwards branch after 3.1 is out
> and then start to improve analyzers, we then will have the maintenance hell
> for backwards tests. And we loose backward compatibility testing for older
> versions. If we would specify a specific version like LUCENE_31 in our tests,
> after moving to backwards they must work without any changes!
> To not always modify all tests after a new version comes out (e.g. after
> switching to 3.2 dev), I propose to do the following:
> - declare a static final Version TEST_VERSION = Version.LUCENE_CURRENT (or
> better) Version.LUCENE_31 in LuceneTestCase(4J).
> - change all tests that use Version.LUCENE_CURRENT using eclipse refactor to
> use this constant and remove unneeded import statements.
> When we then move the tests to backward we must only change one line,
> depending on how we define this constant:
> - If in trunk LuceneTestCase it's Version.LUCENE_CURRENT, we just change the
> backwards branch to use the version numer of the released thing.
> - If trunk already uses the LUCENE_31 constant (I prefer this), we do not
> need to change backwards, but instead when switching version numbers we just
> move trunk forward to the next major version (after added to Version enum).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
