PostgreSQL 9.2beta3 just came out this week and it sounds like 9.2.0 is only about 2 months away from release.
For windows users, we don't have PostGIS for 9.2 yet on stackbuilder, but we have something perhaps even better.
We have automated windows builds of the PostGIS 2.1 branch for 9.2 for both 32-bit and 64-bit Windows. We still have to revise these to build against beta3,
but the version compiled against beta2 seems to work fine against the EnterpriseDb beta3 install. We also have the build bot
building for 9.1 windows 64-bit and 9.0 64-bit. You can get these at
http://www.postgis.org/download/windows/pg92/buildbot.
If you want to try out the new PL/V8JS and PL/CoffeeScript languages that are great companions for PostgreSQL 9.2 integrated json support. We happen to have windows plv8 binaries for those too
which you can use with the Windows 9.2.0 beta 3 binaries
which you can just copy in your PostgreSQL 9.2 installs and install with a quickie:
CREATE EXTENSION plv8js;
CREATE EXTENSION plcoffee;
You can follow our PL/Javascript and PL/CoffeeScript series. We are still
getting our feet wet, but hope to show some nice integraton features with PostGIS JSON support in later parts.
Supporting software the challenges
Sadly it looks like 9.2 will be out before PostGIS 2.1. We are planning to drag our feet long-enough so that we don't have to bother releasing a windows PostGIS 2.0
build for 9.2. We have many reasons for this laziness.
- We build 8.4,9.0,9.1 (both 32-bit and 64-bit) for PostGIS 2.0 for windows. Adding 9.2 will add another 2 (for total of 7 versions)
and also lengthen the time we have to maintain support for 2.0.
- 9.2 has SP-GIST, Paul has intimated he'll be putting SP-GIST support in 2.1
for 9.2 users, so why would you bother using 2.0 if you are
on 9.2? I'm all for not giving users stupid options to consider and encouraging the PostGIS development clan to get that SP-GIST in there.
- If you are a developer of any software -- number one that should be on your mind is how to get users off old releases of your sofware.
Back-porting fixes is time-consuming/expensive and takes away precious time from new-development and documenting new features.
The more users you have running older versions of your software, the more
you are thought of by the limitations of your past. Regardless of if you develop open source or proprietary software, you have
a contract (expectation) from customers about how long you will support patches for a version.
If nobody is using an old version, you don't need to provide bug-fixes to it except possibly security fixes.
Of course you can't just cut the chord. You want people
to naturally stop using old versions and encourage hosting companies to provide newer options (and stop providing old options). The best way
to do that is, more binary distributions of newer releases and beta releases available. Heavily tested beta versions, which happens naturally if you make binary distributions
available and minimize on breaking changes.
Great usability features that are easy for a user to upgrade from one version to the next and possible within reason backwards compatibility so that people
don't have to do a lot of testing of their old apps to be sure it works with the new version.
With all that in mind, it's my personal challenge to make it easy for current PostGIS 2.0 users to test out the latest 2.1 changes on real workflows and be able to upgrade often.
The upgrade issues I discussed in the last article, are for the time being resolved and users should be able to run the minor upgrade script to upgrade to the latest 2.1.0SVN.
For extension users, you can employ the hack described in upgrade to non-released PostGIS, except I have the files now being autobuilt as part of the extension build.
If you are on 2.0.0 or 2.0.1 then:
ALTER EXTENSION postgis UPDATE TO "2.1.0SVN";
If you are on some version of 2.1.0 then:
ALTER EXTENSION postgis UPDATE TO "2.1.0SVNnext";
ALTER EXTENSION postgis UPDATE TO "2.1.0SVN";
