[postgis-users] Roadmap for next major release of PostGIS
Gregory.Williamson at digitalglobe.com
Wed May 28 04:08:49 PDT 2008
Given that there is going to have to be pain eventually to make this code base more coherent / maintainable, I think what you outline is sensible. 7.4 is going to be sunsetted "soonish" anyway and supporting it seems to be less than sensible; 8.0 we here at my company skipped because it just seemed to have issues and the later releases have given more bang for the non-buck ;-) . The decision on Windoze support seems quite in line w/ PostgreSQL in general.
I'd rather see a freeze on new features and some work done to make the long-term prospects better than see developers increasingly spin their wheels trying to maintain old code bases. Take advantage of newer features in postgres where possible since they've done work for a reason. But what a refreshing idea to be able to contemplate going back and fixing old issues and cleaning up things instead of pasting new functionality onto increasingly rickety infrastructure!
A caveat -- all in favor of a tighter coupling of postGIS and GEOS but do make this as painless as possible for neophytes and others who are not masters of their own environments, either from lack of experience or from being dependent on arbitrary sysads. (i wish for several moons)
I can't offer much personally -- a little geld [hundreds of US dollars -- act now before this offer becomes meaningless!] if you need it, some perl experience [not a wizard mind you!] and maybe some help testing. "Corporate" I do not speak for but my guess is that they're more willing to pony up money for specific features that are needed rather than general under-the-hood work. But I think this sounds like a good idea and well worth doing sooner rather than later. So let me know if I can help.
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
(My corporate masters made me say this.)
From: postgis-users-bounces at postgis.refractions.net on behalf of Mark Cave-Ayland
Sent: Wed 5/28/2008 3:12 AM
To: PostGIS Users Discussion; PostGIS Development Discussion
Subject: [postgis-users] Roadmap for next major release of PostGIS
After various discussions on the -devel mailing list, we felt that it
would be worthwhile sending an email to -users to give an idea of where
we see PostGIS development going in future, and make sure that there are
Firstly, a bit of background with regard to PostGIS: all of the current
release support versions of PostgreSQL back to 7.3, but unfortunately
this comes at a cost. PostGIS tends to hook into PostgreSQL in some very
low level places where API changes can be quite frequent, resulting in
large chunks of very nasty looking bits of #if...#endif code.
Unfortunately, this means that there may be multiple execution paths
through critical code sections, and unless you compile against every
release of PostgreSQL then it's fairly easy to miss one of the code
paths and only partially fix a bug. There are also similar problems with
GEOS/PROJ.4 in that it is possible to build with one, the other or
both libraries. Each of these exposes different code paths, and unless
you compile with every library combination, it's very easy to forget to
add in the new function definitions and cause errors within lwpostgis.sql.
Another problem with the existing code base as it stands is that the
build system is horrendously complicated; in order to build PostGIS
without a source tree, the SVN repository contains large chunks of
hacked Makefiles imported and modified from the PostgreSQL build system.
Maintenance of these is an uphill struggle, as it is almost impossible
to know whether a change will break some of the less-known builds. The
current build system is also tied heavily into autoconf; it is very
difficult to use other platforms such as MSVC due to the way the
existing configuration works.
There are also other factors to consider, outside of the PostGIS arena.
The most significant of these is to do with support; the PostgreSQL
development team now only officially support from 7.4 upwards, and
indeed the Win32 team only officially support from 8.2 upwards. (Note: I
use officially since other suppliers, e.g. RedHat and other companies
may offer extended long term support)
At the end of the day, we want to deliver a product that is easy to
maintain whilst keeping the sanity of the developers and the high level
of reliability to which we have all become accustomed. So as a result of
this, the 1.3 series has now been officially branched within SVN, with
the following development roadmap for trunk:
- Rework the autoconf build system to use autoheader/PGXS
The autoconf system was never being used to its full potential; a new
build system will be much easier to maintain, and should open the door
for easier compilation on other platforms, in particular MSVC.
As a consequence of this, support for PostgreSQL < 8.1 will be removed.
Also, in line with the official PostgreSQL development policy, Win32
installers for releases before PostgreSQL 8.2 will NOT be produced
- Make PROJ.4/GEOS compulsory dependencies for the build
This will allow us to remove more #if...#endif statements related to
producing special versions of PROJ.4/GEOS functions in the case where
different combinations of libraries are present. This will make life
much easier for developers.
- Removal of legacy code
This will allow us to rip out huge chunks of code, particularly in
relation to the pre-PostgreSQL 8.0 statistics code (think SELECT
- Rewrite the regression test harness
The regression test harness is currently written as a shell script,
which makes running regression tests under Win32 only possible under
MingW. In order to support an MSVC build, it is intended to re-write the
regression test script in Perl (which is required to build PostgreSQL
In terms of support, we hope to be able to maintain the 1.3 branch until
the end of the 1.3.x series. It may be that some patches/fixes are not
backpatchable to the 1.3 series, however we will try our best to keep
both the 1.3 branch and SVN trunk up to date with patches/issues on the
PostGIS bug tracker.
Apologies for the length of this email, but I hope it gives a good
indication of where we are planning to go with future developments. I
don't think there will be too many surprises (see the archives for
previous posts about dropping support for older PostgreSQL versions),
but if anyone has any arguments/comments, I would encourage you to reply
to this thread.
[Note: I have also CC-d to postgis-devel, but please keep any resulting
discussion on postgis-users]
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063
postgis-users mailing list
postgis-users at postgis.refractions.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-users