db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Andrew McIntyre <fuzzylo...@nonintuitive.com>
Subject [VOTE] Derby versioning
Date Tue, 05 Oct 2004 17:49:23 GMT
Hash: SHA1

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:


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).


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

Version: GnuPG v1.2.4 (Darwin)


View raw message