[postgis-devel] Versioning and Branching Rationale

[alex bodnaru]

hi strk,

i'm working on debianizing postgis-1.1.

the funny thing, is that postgis-1.0.4 just entered new packages queue.
but 1.1 will go on it's path soon.

i wish to ask you, whether postgis 1.0.x could run on an upgraded
postgis-1.1 database (for recovery purposes).
this may influence my decision to source lwpostgis_upgrade.sql upon
postgis-1.1 installation.
as i understand, finding a previous 1.* postgis will outrule the case
there is no postgis installed.

i have double-checked the configure.in script again, and i am attaching
it here (sorry not a diff). it adds --with-datadir arg, and is able to
recognize newer --with-docdir configuration arg in postgresql. the
postgresql --configure --datadir arg is also recognized.
those are extremely useful for installing postgis in our current
postgresql architecture, that allows multi postgresql versions
installations.

also, lwgeom/Makefile has inconsistent install/uninstall directories.
attached again, sorry.

i hope, that after this release (+debian), we'll find the time to better
integrate postgis 0.* stuff with current functionality.

thanks,
alex

strk at refractions.net wrote:
> 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 
> --------
> 
> 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:
> 	postgis_version()
> 	postgis_full_version()
> 	postgis_lib_version()
> 	postgis_scripts_released()
> 	postgis_scripts_installed()
> 
> 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.
> 
> 
> Branching
> ---------
> 
> 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.
> 
> 
> --strk;
> 
>  /"\    ASCII Ribbon Campaign
>  \ /    Respect for low technology.
>   X     Keep e-mail messages readable by any computer system.
>  / \    Keep it ASCII. 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure.in
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20051219/5f9e14e4/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20051219/5f9e14e4/attachment-0001.ksh>