db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject version scheme
Date Thu, 26 Aug 2004 18:10:19 GMT
Hash: SHA1

This is an overview of how the version scheme is set up in the Derby
code and was intended to work for Cloudscape.

I hoping to start some discussion on how Derby would move forward with
versions, e.g. to continue using the same scheme? What would trigger a
bump in any of the version numbers? Etc.


[this e-mail covers the basic numbering scheme, the next will cover upgrade]

Externally the code uses a four part version number

~  Minor.major.fixpack.point  or M.m.f.p

the initial version (as in the code drop from IBM) is set to

Major.minor is a typical major and minor release numbering scheme and
maps to the version scheme expected by JDBC (major and minor version
numbers for Driver and Database). A change in these numbers indicated
new functionality in Cloudscape, typically that which modified the
on-disk format in some way that would not be understood by an older
release, e.g. support of a new SQL catalog item such as triggers.
For Cloudscape each M.m version had its own (and only one) branch in the
Perforce SCM system.

The point (p) value was increased every time a "point release" of
Cloudscape was made, which were releases with a bug fix or fixes for
customers. The point releases were always cumulative, that is
would include the fixes of as well as the new bug fix(es).
Point releases did not contain changes that changed the on-disk format
of databases. Testing on point releases was restricted to nightly
functional testing as a point release was usually in response to a
customer issue, sothe fix had to be released within a few days of the
report. As a "closed-source" project IBM could control releases so that
the point number was only bumped when the software was actually released
to a customer, regardless of the number fixes between releases.

Fixpack was intended to indicate a release of a given Major.minor that
had undergone more testing than a point release, e.g. a multi-week
quality assurance (QA) testing cycle. A fix pack release would include
all the fixes of the previous point release, e.g. would include
all the fixes from if that was the most recent point release
for 10.0.
Fixpack (f) of 0 (zero) is a special value that indicates alpha quality
software and causes version string to be appended with the word "alpha".

Additionally a boolean beta flag exists, which when true causes the
version string to be appended with the word "beta" to indicate beta
quality software. The initial code drop has the beta flag as false.

A build number can also be set which corresponded to the Perforce (SCM)
global change number for Cloudscape.

The single branch model for a M.m used by Cloudscape meant that
customers never received special one-off releases. A customer that
needed a new release for a newly discovered bug always received a point
release with all the bugs fixed for that branch and the new bug fix.
E.g. a customer that was using and found a new bug, might
receive a point release that was, thus included all the fixes
in the 10.0 branch and had undergone 3 additional QA testing cycles.

- -------------------------------------------------------------------------

This version value is reported by the sysinfo utility, in some messages
and in the java.sql.DatabaseMetaData methods as follows

String getDatabaseProductVersion()
String getDriverVersion()
~  both return M.m.f.p [ {alpha|beta} ]

int getDatabaseMajorVersion()
int getDriverMajorVersion()
~  both return M

int getDatabaseMajorVersion()
int getDriverMajorVersion()
~  both return M

int getDatabaseMinorVersion()
int getDriverMinorVersion()
~  both return m

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


View raw message