[postgis-users] Roadmap for next major release of PostGIS

Gregory Williamson Gregory.Williamson at digitalglobe.com
Wed May 28 04:08:49 PDT 2008


+1

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.

Greg Williamson
Senior DBA
DigitalGlobe

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.)



-----Original Message-----
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
 
Hi everyone,

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 
no surprises.

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 
update_geometry_stats()).

- 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 
under MSVC).


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]


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20080528/e8ad4104/attachment.html>


More information about the postgis-users mailing list