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: neutral (hermes.apache.org: local policy)
Message-ID: <4163347D.7000002@sbcglobal.net>
Date: Tue, 05 Oct 2004 16:55:41 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [VOTE] Derby versioning
References: <E4832FA7-16F6-11D9-9C67-003065905854@nonintuitive.com>
In-Reply-To: <E4832FA7-16F6-11D9-9C67-003065905854@nonintuitive.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

I believe this along with the upgrade policy is key to building
a large user community and still allow aggressive development.  With
this users are promised that their applications will continue to
work with no upgrade necessary on a given release, and provides
the information necessary to move to a major release.

+1

Samuel Andrew McIntyre wrote:

| To address this:
|
| Kathey Marsden wrote:
|
|>>
|>> 6) A consensus is reached on the Derby versioning scheme.
|>>
|
| and as this is related to the upgrade policy in the "[VOTE] Derby
| upgrade policy", I propose the following:
|
| That the version scheme currently in place, and described in:
|
| http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-
| dev@db.apache.org&msgNo=73
|
| be accepted in order to facilitate the upgrade policy voted on and
| accepted in the Derby upgrade policy thread. As such, Derby versions
| should take the following form: MAJOR.Minor.interim.point {beta} (build
| identifier). As an example, the currently posted snapshot version of
| Derby is 10.0.2.0 (46005).
|
| Whereby:
|
| Differences in the major version are used to identify large changes in
| architecture and functionality, and for which upgrade is required.
| Differences in the minor version are used to identify changes in
| functionality large enough to require an upgrade procedure for
| databases from the previous version, and for which upgrade is required.
| Differences in the interim version are used to identify significant
| differences in behavior of the database engine from the previous
| interim version, but for which upgrade to databases is not required.
| Differences in the point version are used to identify that any amount
| of change to the database engine has occurred from the previously
| released point version.
| That the build identifier be used to distinguish the exact state of the
| code from which any specific set of binaries have been compiled,
| That the beta flag in the version denote that the upgrade policy is in
| an indeterminate state with respect to the previous version and, as
| such, that an upgrade to a beta version of Derby is allowed, but an
| upgrade from a beta version of Derby to any other version of Derby is
| not allowed.
|
| I would like to further propose that, following that version scheme,
| that releases from any branch have a specific version number and be
| tagged in the repository. Thus, following this version scheme, the
| forthcoming baseline release of Derby should be versioned 10.0.2.1, as
| it includes changes which are not included in the first public version
| of the source. Once the release is ready, the version on the trunk will
| be changed to 10.0.2.1 and then tagged in subversion.
|
| I would like to also further propose that before changes which would
| require upgrade are allowed into the trunk, that the trunk be branched,
| so that the branch can serve as the reference for the upgrade policy.
| After branching, the minor (and/or major) version of the trunk will be
| incremented, and the beta tag applied to indicate that significant
| changes exist in the trunk which would require database upgrade and
| that the code for performing the upgrade has not been rigorously
| tested. As an example, before a change could be applied which would
| require upgrade, a new 10.0 branch would be created and the trunk would
| be reversioned 10.1.0.0 beta, in order to distinguish the trunk from
| the new branch and to allow changes that require a database upgrade
| into the trunk.
|
| and my vote: +1
|
| andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBYzR7EpeslyHqPs0RAkosAKDapsZ3WKL/rFBaeFUhBZHiwbRR9gCfQLO0
2UQl4cJwOFJF88+EaTR238s=
=skVZ
-----END PGP SIGNATURE-----