Opened 12 years ago

Closed 12 years ago

#1944 closed defect (fixed)

Extensions Migration path from 2.1.0 to 2.1.0

Reported by: robe Owned by: robe
Priority: critical Milestone: PostGIS 2.1.0
Component: build Version: master
Keywords: Cc:

Description

I'm planning to implement my workardoun to encourage testing of pre-versioned builds.

The plan -- always have a

PostGIS-2.1.0SVN--PostGIS-2.10SVNnext.sql

PostGIS-2.1.0SVNnext--PostGIS-2.1.0SVN.sql

As I describe here: http://www.bostongis.com/blog/index.php?/archives/190-How-to-Use-PostGIS-Extensions-to-upgrade-to-non-released-PostGIS-versions.html

So that way people who are using the extensions model, but also want to be able to upgrade non-released versions will play a yoyo game of

ALTER EXTENSION postgis UPDATE TO "2.1.0SVNnext";
ALTER EXTENSION postgis UPDATE TO "2.1.0SVN";

Before I do this, we really got to fix the upgrade scripts (since they are broken both for extension and for 9.0 builds if you are coming from 2.0) so they actually work for early 2.1.0 releases and 2.0.+ releases. Without this I feel we aren't going to get any serious testing which is essential.

Change History (5)

comment:1 by robe, 12 years ago

Priority: mediumcritical

comment:2 by strk, 12 years ago

Do I see space for an "ALTER EXTENSION" command improvement there ? Like a FORCE modifier at the end ?

comment:3 by strk, 12 years ago

or is the version of the script really only found in the file itself ? Because we could then have the file contain the version including SVN revision id and always use the same syntax (every run will find a different version in the script)

comment:4 by robe, 12 years ago

It's only in the file name not the actual script. The way we got around for the 2.0.0 is that we would just create copies of the same upgrade script with different version numbers -- when we were in the beta1,beta2 etc. phases.

Since we have no fixed milestones yet, that would just add unnecessary clutter of copying the same file. That's why I dismissed having the file contain the version number.

Let's say a user is at r12345 and they skip r12346 and then jump back on r12349. You don't want all that clutter with same file repeated to guarantee they can upgrade from where they are.

comment:5 by robe, 12 years ago

Resolution: fixed
Status: newclosed

fixed r10171, r101172 , r10174 , r10175

Now you can upgrade both postgis and postgis_topology with below if you are already running a 2.1.0SVn

ALTER EXTENSION postgis_topology UPDATE TO "2.1.0SVNnext";
ALTER EXTENSION postgis_topology UPDATE TO "2.1.0SVN";
ALTER EXTENSION postgis UPDATE TO "2.1.0SVNnext";
ALTER EXTENSION postgis UPDATE TO "2.1.0SVN";
Note: See TracTickets for help on using tickets.