Go back to having different scripts version from postgis lib version

[robe]

Propose to change select postgis_full_version(); and postgis_scripts_installed()

So postgis_scripts_installed() will just read '1.4'

and postgis_full_version() will not complain if dll/so version starts with 1.4 and scripts installed starts with '1.4'

Also we will not be changing scripts at all during MICRO version upgrades.

Not sure if we should slate this for 1.5 or 1.4.1

See discussion with Dave and Mark ​http://postgis.refractions.net/pipermail/postgis-devel/2009-August/006687.html

[robe]

Sorry for making a big deal out of this. Apparently I misunderstood how this upgrade message is actually generated. Reading strk email, I understand now the solution that will hopefully satisfy everybody.

In the configure.ac we have this line

POSTGIS_SCRIPTS_VERSION="$POSTGIS_LIB_VERSION"

That is really the cause of my frustration as it always made the postgis_full_version() read that one needs an upgrade of scripts even when scripts did not change from micro to micro. Its not an issue when you have only one spatial database, but when managing many its a bit annoying.

So I propose -- go back to the pre 1.1 days when we have a different SCRIPTS VERSION from POSTGIS LIB VERSION. I've changed the title of this accordingly.

[pramsey]

I'm sorry, it's not clear what you want changed, a patch would be helpful.

[pramsey]

OK, I understand now, but I don't agree. Having a separate scripts version would require that we manually manage it, remembering to increment it when scripts change. If we fail, then the system falls apart. It's easy to know when to upgrade the libs version -- when we're cutting a release.

[robe]

Okay lets punt this one. It seems my idea of not having to change scripts in minor versions that often is not working out anyway as the 1.4.1 already has changes in the .sql file. I suppose we can revisit if the need arises.

[robe]

Regina-- Yes that was why I thought we needed this change, because a large part of the utility of no-API changes is gone if you have to keep on running upgrade scripts after each install on each postgis enabled database you run.

From a large databases farm perspective -- I envisioned the db admin would run the PostGIS upgrade and spot check the first one to verify upgrade scripts had not changed and then call it a day. if problems should arise he/she could then revert back to the old so/dll

But evidentally no one else cares about this but me so I concede defeat :(.

---

Pauls's note: This raises an issue of policy which our "API stable" promise makes perhaps worth articulating: functionality should be implemented primarily in the C library. Otherwise we're going to have this issue, of "bugs in the SQL" which cannot be solved by a library drop-in, and that require extra DBA attention.

If the goal of "no SQL upgrades" is paramount, then moving more code into C makes sense.

P.

[pramsey]

There's a script utils/read_scripts_version.pl now that answers the question of how to reliably derive a scripts version number at release time. If you want to articulate the release process and upgrade process around that, Regina, please feel free to do so. I may come back to this later next week when I start looking at upgrade issues, but that's not going to happen until I close out more tickets.

[robe]

Paul,

Thanks -- I took a quick look at this script and it looks promising and an elegant solution to the problem. Good solution though haven't figured out yet how this would tie in with our build of the postgis.sql file (unless we just amend our how to release to include this perl check step and keep manual for now)

So our scripts version numbers would now be POSTGIS_MAJOR.POSTGIS_MINOR.SVNVERSION

e.g. 1.5.(svnversion since last script changed output from perl script)

So I take it the challenge is to In our postgis_scripts_released() function -- some how stuff this perl gotten revision number in there.

In our postgis_scripts_installed sql function -- some how stuff this perl gotten revision number in there.

Or just take the manual way for now and hardcode it accordingly by manually running the perl script to get the number. Would be nice if we could automate it though.

So I guess this means I can reopen this?

[robe]

Okay I thought about this a bit more and Paul while I like your concept -- wouldn't it be easier to automate as part of our compile process if we just grep sed the .sql.in.c files and read the svn version from the head of the files rather than doing an http call. They all have a line of the form:

$Id: uninstall_long_xact.sql.in.c 4494 2009-09-14 10:54:33Z mcayland $

That would remove perl out of the mix and assume would therefore make it easier to isolate to our configure.ac. Similar to what we do already in the configure.ac (for POSTGIS_..VERSION) and I assume that logic could then be built directly in the configure.ac file.

Then the line configure.ac line 575 would change to

POSTGIS_SCRIPT_SVN_VERSION = magical wonderful grep sed to read latest svn version from head of .sql.in.c files
POSTGIS_SCRIPTS_VERSION="$POSTGIS_MAJOR_VERSION.$POSTGIS_MINOR_VERSION.$POSTGIS_SCRIPT_SVN_VERSION"

Though its the magical wonderful part I can't figure out how to write :) Anyone have any clues on that. I guess for 1.5 we can just hardcode it for now if my magical wonderful dream is not a trivial exercise for someone.

[pramsey]

This doesn't feel appropriate for a point release, moving to 1.5

[pramsey]

Code to do the automagic script version generation committed at r4837

[pramsey]

Tested and seems to work, final commit at r4838 to remove micro-version from scripts version.