lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts
Date Thu, 04 Feb 2010 09:42:28 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-2248:
----------------------------------

    Description: 
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).

  was:
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 propse 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).

        Summary: Tests using Version.LUCENE_CURRENT will produce problems in backwards branch,
when development for 3.2 starts  (was: Tests using Version.LUCENE_CURRENT will produce problems
in backwards branch, wen development for 3.2 starts)

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message