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 , 12 years ago
Priority: | medium → critical |
---|
comment:2 by , 12 years ago
comment:3 by , 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 , 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 , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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";
Do I see space for an "ALTER EXTENSION" command improvement there ? Like a FORCE modifier at the end ?