Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1200160381.1229349584514.JavaMail.jira@brutus>
Date: Mon, 15 Dec 2008 05:59:44 -0800 (PST)
From: "Ole Solberg (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3982) Add a facility to override the default
 set of old versions to be tested in the upgrade tests.
In-Reply-To: <563829282.1228918004397.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ole Solberg updated DERBY-3982:
-------------------------------

    Derby Info:   (was: [Patch Available])

Thanks for catching that Rick!
I am testing a new patch...

> Add a facility to override the default set of old versions to be tested in the upgrade tests.
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3982
>                 URL: https://issues.apache.org/jira/browse/DERBY-3982
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions: 10.5.0.0
>            Reporter: Ole Solberg
>            Assignee: Ole Solberg
>            Priority: Minor
>         Attachments: DERBY-3982_diff.txt, DERBY-3982_stat.txt
>
>
> In my testing I have seen a need for performing upgrade testing from local/internal non-public "versions" of Derby.
> That is, having local/internal changes to some older branch and allowing upgrade testing from this (not yet public) version.
> One solution is to locally modify the 'VERSIONS' table of the upgradetests '_Suite', but this means modifying the source for each such case.
> A more flexible solution is to override the default versions (given in 'VERSIONS') by using a property giving a file which lists the versions to test upgrade from. The location to local version jars can currently be given by the 'derbyTesting.oldReleasePath' property. The list of versions could be given by a property 'derbyTesting.oldVersionsPath'.
> This will also easily allow us to skip testing upgrade from a specific version. (This can already be done by not having the version jars available.)
> The list of versions given via the property should be used whether versions (jars) are available locally (as given by the 'derbyTesting.oldReleasePath' property or fetched from the Apache Derby svn repository ('http://svn.apache.org/repos/asf/db/derby/jars').
> I have a patch for this which I will submit for review.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.