Opened 15 years ago

Closed 14 years ago

#242 closed defect (fixed)

Go back to having different scripts version from postgis lib version

Reported by: robe Owned by: pramsey
Priority: medium Milestone: PostGIS 1.5.0
Component: postgis Version:
Keywords: Cc:

Description

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

Change History (11)

comment:1 by robe, 15 years ago

Summary: Get rid of Micro version numer in postgis_scripts_installed and postgis_full_version checkGo back to having different scripts version from postgis lib version

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.

comment:2 by pramsey, 14 years ago

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

comment:3 by pramsey, 14 years ago

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.

comment:4 by robe, 14 years ago

Resolution: wontfix
Status: newclosed

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.

comment:5 by robe, 14 years ago

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.

comment:6 by pramsey, 14 years ago

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.

comment:7 by robe, 14 years ago

Resolution: wontfix
Status: closedreopened

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?

comment:8 by robe, 14 years ago

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.

comment:9 by pramsey, 14 years ago

Milestone: postgis 1.4.1postgis 1.5.0

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

comment:10 by pramsey, 14 years ago

Code to do the automagic script version generation committed at r4837

comment:11 by pramsey, 14 years ago

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.