Reviewing the following will make it easier for you to navigate our website
and find the proper version of ExtSQL for your needs. Our version
names may seem long (and they are long!), but because we are supporting both
older, current, and custom version of ExtSQL for both MySQL and PostgreSQL -- it
can get confusing!
| What's in a binary or source distribution? |
|---|
A hyphen '-' separates parts of a name. Let's start with the names of our downloads, for example:
extsql-my-bin-4.1.22-rhel4-x86-1-7-3.0.tar.gz : One of our precompiled binaries for MySQL. It contains:
extsql-my-bin-4.1.22-rhel4-x86-1-7-3.0 :
The replacement for mysqld
do_conf-4.1
: The configure options used.
README.binary_extsql
: Installation instructions.
extsql-my-src-4.1.22-rhel4-x86-1-7-3.0.tar.gz : A source distribution for MySQL. It contains:
do_conf-4.1
: The configure options used.
patch-4.1.3.0
: Primary patch file containing most changes for ExtSQL.
compat-4.1.7
: Additional patch file containing more version specific changes.
README.source_extsql
: Build and installation instructions.
| What's in a name? |
|---|
FIRST THREE PARTS: Always starts with
extsql, followed by 'my' for a MySQL build or 'pg' for a PostgrSQL build; then
followed by 'bin' for a binary distribution or 'src' for a source version.
So....
extsql-pg-bin - Starts a binary distribution for PostgreSQL, extsql-pg-src -- a source distribution for PostgreSQL
NEXT SIX PARTS: These represent the 'ingredients' selected to build that version, for example, separating 4.1.22-rhel4-x86-1-7-3.0 to explain its six parts:
| MySQL/PostgreSQL version |
Operating System (OS) |
Architecture (Arch) |
Config | Compat | Patch |
| 4.1.22 | rhel4 | x86 | 1 | 7 | 3.0 |
| This number matches the version numbering used for the compatible version of MySQL or PostgreSQL |
The operating system and architecture. A full description of our current designators can be found via our download pages. | The option file used for the 'configure' command. | The compatibility file used as part of the patch process. | The primary patch file used to create ExtSQL | |
Understanding the Config-Compat-Patch sequence: These identifiers record which combination of files was used to taylor the DB server to support ExtSQL capability.
Config: 1 (refers to file do_conf-4.1) - In our build system the '4' is presumed (the MySQL major version number is already known by the MySQL version info) and not repeated in our build identifier sequence. The '1' is an increasing number which represents specific build options, normally the '1' version represents a build performed with the same config options as any precompiled binary distribution from MySQL or PostgreSQL.
We realize that many people are running with different configure options. Our download pages are designed to allow people to 'vote' (express their interest) in specific configure options -- our automated build system allows us to quickly build/test a precompiled binary to match your platform.
Compat: 7 (refers to file compat-4.1.7) - In our build system the '4.1' is presumed (the MySQL major/minor version number is already known) and not repeated. The '7' is an increasing number which represents a specific file version.
During the development of the ExtSQL patch set we learned how hard it is to create patches valid across multiple source versions -- especially when we expected to upgrade the patch set and then reapply to those varied versions. The 'Compat' file contains patches to files that were found to change infrequently and were specific to certain DB server versions.
Patch: 3.0 (refers to file patch-4.1.3.0) - The '4.1' is presumed as described above. The '3.0' represents detailed patch version info. The '3' represents a change in ExtSQL functionality/usage syntax. The next digit, in this case '0', represents any bug fix releases, e.g. 3.0 is the first patch release with certain functionality. A release called 3.1 would not have any additional functionality, but just include any bug fixes. A release called '4.0' would represent something new in patch functionality.
Our download system allows you to get a detailed listing of all Change Requests (CRs) that are opened/closed in a specific release.