[postgis-devel] Versioning and Branching Rationale

strk at refractions.net strk at refractions.net
Fri Dec 16 02:24:47 PST 2005

After a long session with our excellent System Architect we
finally have a *simple* versioning scheme (thanks, Paul).

Versions unification

PostGIS core has a SINGLE version.
No more SCRIPTS version.


Upgrades between MINOR.MICRO releases only require
sourcing the `lwpostgis_upgrade.sql' script:

	psql -f lwpostgis_upgrade.sql <spatial_db>

Upgrades between MAJOR releases require dump/reload
as described in the HARD UPGRADE section of the manual.

Parallel installations

Parallel MAJOR PostGIS release installations are
supported on *all* architectures.

Parallel MINOR PostGIS release installations are
NOT supported (altought technically possible on
most archs).

Version printing functions

PostGIS version returned by sql functions
always refer to the unified version numbers.

This includes:

The postgis_scripts_installed() is a procedural
function, with version hard-coded in its body.
This allows checking of lib/scripts matching.
The check is performed automatically by
postgis_full_version() warning you in case you
forgot to upgrade an existing spatial db.

The postgis_lib_version() and postgis_scripts_released()
functions will return the same value.

The postgis_version() function will retain its format
for backward compatibility. This means that MICRO
version will NOT be shown.


CVS branches will only be defined for MAJOR releases.
Branches between MINOR.MICRO releases will be avoided.
As a consequence the 1.0 branch is abandoned and 1.0.x
installations will not be considered in any special way.

Currently supported branches are: 0.x and 1.0.
For historical reasons these are respectively tagged
as: pgis_0_9_0 and HEAD.


 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII. 

More information about the postgis-devel mailing list