Mailing List Archive: Lucene: Java-Dev

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts

Index | Next | Previous | View Threaded

jira at apache

Feb 4, 2010, 1:42 AM

Post #1 of 6 (763 views)
Permalink

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts

[ 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Feb 6, 2010, 9:27 AM

Post #2 of 6 (702 views)
Permalink

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts [In reply to]

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

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

Attachment: LUCENE-2248.patch

Here my first patch. Please tell me which name for the static constant should be used, I use CURRENT_VERSION. Maybe something with "test" in it?

I transformed TestCharArraySet as a demonstation.

> 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
>
> Attachments: LUCENE-2248.patch
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Feb 6, 2010, 10:59 AM

Post #3 of 6 (701 views)
Permalink

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts [In reply to]

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

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

Attachment: LUCENE-2248.patch

Patch with updated constant name.

Simon, if you like you can use it as basis and start with contrib.

> 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
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2248.patch, LUCENE-2248.patch
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Feb 8, 2010, 4:40 AM

Post #4 of 6 (663 views)
Permalink

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts [In reply to]

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

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

Attachment: LUCENE-2248.patch

Here the patch for all core tests.

I also did a eclipse import cleanup to remove the unused Version imports. Now the code is also clean from a full-specified class name (o.a.l.util.Version.LUCENE_CURRENT), I introduced during my 3.0 refactoring (I did not add the import statements at this time).

I would like to commit this soon, if nobody objects, because the patch could get out of sync very fast.

> 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
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2248.patch, LUCENE-2248.patch, LUCENE-2248.patch
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Feb 8, 2010, 5:30 AM

Post #5 of 6 (656 views)
Permalink

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts [In reply to]

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

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

Attachment: LUCENE-2248.patch

Updated patch, I missed some LUCENE_CURRENT occurences. Now all are catched and changed. My sed-command was wrong (missed to replace all occurences in one line) :-)

All test pass still. Will commit if nobody objects this evening.

> 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
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2248.patch, LUCENE-2248.patch, LUCENE-2248.patch, LUCENE-2248.patch
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Feb 10, 2010, 5:38 AM

Post #6 of 6 (593 views)
Permalink

[jira] Updated: (LUCENE-2248) Tests using Version.LUCENE_CURRENT will produce problems in backwards branch, when development for 3.2 starts [In reply to]

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

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

Attachment: LUCENE-2248.patch

I forgot to add the latest patch.

> 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
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2248.patch, LUCENE-2248.patch, LUCENE-2248.patch, LUCENE-2248.patch, LUCENE-2248.patch
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads