db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [VOTE] Derby versioning
Date Tue, 05 Oct 2004 23:55:41 GMT
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.


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 (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, 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 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 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
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


View raw message