Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <41586E6B.4000608@debrunners.com>
Date: Mon, 27 Sep 2004 12:47:55 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: [VOTE] Derby upgrade policy
References: <413E2E8C.6070200@debrunners.com>
 <001901c49777$db7692a0$0200000a@lan>
 <09607C0D-03BE-11D9-A09C-003065905854@nonintuitive.com>
 <41487157.7090702@Sourcery.Org>
In-Reply-To: <41487157.7090702@Sourcery.Org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[in the Thoughts on a release thread]

Kathey Marsden wrote:

> I suggest adding:
>
> 5) A consensus is reached on the Derby upgrade policy.


To address this I propose a vote to accept that for any release of Derby
 the upgrade policy described in
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgNo=77
is followed.

The summary is that any release of Derby can run against a database
created by a previous release with either no upgrade, soft upgrade or
hard upgrade mode, depending on the circumstance.

This would mean that if some new feature was added to Derby, before a
release occurred the correct upgrade code would have to be written, if
the feature contributor did not provide it.

My vote: +1

Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBWG5rIv0S4qsbfuQRAmxkAJ9ePo998kjv48sPqD93iq2lOiBFUwCg4/Tw
A+mIS9R0yaBWCAO62N4v3qw=
=gHou
-----END PGP SIGNATURE-----