[postgis-devel] Small boo boo

[Paragon Corporation]

Strk,

As of PostGIS 1.4 -- the PostGIS steering committee decided that in a micro
version we will no longer allow the addition of functions, nor the changing
of interface of existing functions.  I suggesting on top of that -- no SQL
file changes because that's really the point of all of this.

So what Mark is saying is since SQL file will not change, there is really no
need to have an SQL part that checks for script version. I'm actually in
disagreement with that, since one could have accidentally run the wrong sql
file from a previous version (I know its happened to me before I can only
imagine its happened to others).  So I feel this check is still needed.

But the point is 
>From micro to micro version there should be no need to run an sql file since
the script aint supposed to change.  So the scripts should not be marked
with the micro version is my point.

What do we get as a return
1) Stack builder is easier in the sense that if you need to upgrade your
micro version -- you simply install ontop of your existing and you don't get
registry junk left behind from older micros since it will simply overwrite
the 1.4 registry (instead of adding a 1.4.1 item).  No script to install
since well scripts ain't supposed to change.

-- that is by the way why the new one is taking so much longer - we are
changing to write in register PostGIS/1.4 instead of PostGIS/1.4.0 and
testing heavily with install/uninstall on various servers.  There are other
minor things such as PostgreSQL 8.4 is more stringent on encoding so we
needed to get rid of some code.

2) People will be less scared about upgrading (hopefully) -- since they know
a micro will only contain bug fixes and well tested enhancements.
3) Others who don't use installers can simply drop in the new geos, proj
postgis minor dlls and be done with it. This is important if you have lots
of databases running PostGIS.

What do we lose
1) What we used to call micro is now minor which probably means we will have
many more minor releases.  Not a bad thing except in terms of support for
PostgreSQL versions. 

2) I'm suggesting for the minors -- we keep supporting that minor if the
next minor drops support for a PostgreSQL version.  So for example 1.3 we
will keep on back porting critical bug fixes until PostgreSQL group stops
support for 8.1
For 1.4 we keep on back porting critical bug fixes until PostgreSQL stops
support for  8.2
For 1.5 (if 1.6 or 2.0 or whatever comes next no longer supports 8.3, then
we keep porting serious bug fixes to this until PostgreSQL group drops 8.3
support) 

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of strk
Sent: Thursday, August 20, 2009 1:05 PM
To: PostGIS Development Discussion
Cc: Dave Page
Subject: Re: [postgis-devel] Small boo boo

On Thu, Aug 20, 2009 at 11:30:37AM +0100, Mark Cave-Ayland wrote:

> I think the solution will have to be along the lines of "If you have 
> upgraded from 1.4.0 to 1.4.1 and SELECT postgis_full_version() says 
> you need to upgrade scripts, run this .sql file" (although of course 
> some packagers could incorporate this automatically).

This was the whole idea of an SQL implemented version function.
I belive we have both SQL and C functions for versions for making that
possible.

The rationale was that if one just drops an updated DLL w/out updating the
script he should be warned about that.

Micro version updates were allowed (when I last dealt with that) to
introduce new functions or fixes to existing SQL functions so you wouldn't
get in sync if you didn't run the upgrade.sql script.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel