<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [postgis-users] Roadmap for next major release of PostGIS</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>+1<BR>
<BR>
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.<BR>
<BR>
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!<BR>
<BR>
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)<BR>
<BR>
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.<BR>
<BR>
Greg Williamson<BR>
Senior DBA<BR>
DigitalGlobe<BR>
<BR>
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.<BR>
<BR>
(My corporate masters made me say this.)<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-users-bounces@postgis.refractions.net on behalf of Mark Cave-Ayland<BR>
Sent: Wed 5/28/2008 3:12 AM<BR>
To: PostGIS Users Discussion; PostGIS Development Discussion<BR>
Subject: [postgis-users] Roadmap for next major release of PostGIS<BR>
<BR>
Hi everyone,<BR>
<BR>
After various discussions on the -devel mailing list, we felt that it<BR>
would be worthwhile sending an email to -users to give an idea of where<BR>
we see PostGIS development going in future, and make sure that there are<BR>
no surprises.<BR>
<BR>
Firstly, a bit of background with regard to PostGIS: all of the current<BR>
release support versions of PostgreSQL back to 7.3, but unfortunately<BR>
this comes at a cost. PostGIS tends to hook into PostgreSQL in some very<BR>
low level places where API changes can be quite frequent, resulting in<BR>
large chunks of very nasty looking bits of #if...#endif code.<BR>
<BR>
Unfortunately, this means that there may be multiple execution paths<BR>
through critical code sections, and unless you compile against every<BR>
release of PostgreSQL then it's fairly easy to miss one of the code<BR>
paths and only partially fix a bug. There are also similar problems with<BR>
GEOS/PROJ.4 in that it is possible to build with one, the other or<BR>
both libraries. Each of these exposes different code paths, and unless<BR>
you compile with every library combination, it's very easy to forget to<BR>
add in the new function definitions and cause errors within lwpostgis.sql.<BR>
<BR>
Another problem with the existing code base as it stands is that the<BR>
build system is horrendously complicated; in order to build PostGIS<BR>
without a source tree, the SVN repository contains large chunks of<BR>
hacked Makefiles imported and modified from the PostgreSQL build system.<BR>
Maintenance of these is an uphill struggle, as it is almost impossible<BR>
to know whether a change will break some of the less-known builds. The<BR>
current build system is also tied heavily into autoconf; it is very<BR>
difficult to use other platforms such as MSVC due to the way the<BR>
existing configuration works.<BR>
<BR>
There are also other factors to consider, outside of the PostGIS arena.<BR>
The most significant of these is to do with support; the PostgreSQL<BR>
development team now only officially support from 7.4 upwards, and<BR>
indeed the Win32 team only officially support from 8.2 upwards. (Note: I<BR>
use officially since other suppliers, e.g. RedHat and other companies<BR>
may offer extended long term support)<BR>
<BR>
At the end of the day, we want to deliver a product that is easy to<BR>
maintain whilst keeping the sanity of the developers and the high level<BR>
of reliability to which we have all become accustomed. So as a result of<BR>
this, the 1.3 series has now been officially branched within SVN, with<BR>
the following development roadmap for trunk:<BR>
<BR>
<BR>
- Rework the autoconf build system to use autoheader/PGXS<BR>
The autoconf system was never being used to its full potential; a new<BR>
build system will be much easier to maintain, and should open the door<BR>
for easier compilation on other platforms, in particular MSVC.<BR>
<BR>
*****<BR>
As a consequence of this, support for PostgreSQL < 8.1 will be removed.<BR>
Also, in line with the official PostgreSQL development policy, Win32<BR>
installers for releases before PostgreSQL 8.2 will NOT be produced<BR>
*****<BR>
<BR>
- Make PROJ.4/GEOS compulsory dependencies for the build<BR>
This will allow us to remove more #if...#endif statements related to<BR>
producing special versions of PROJ.4/GEOS functions in the case where<BR>
different combinations of libraries are present. This will make life<BR>
much easier for developers.<BR>
<BR>
- Removal of legacy code<BR>
This will allow us to rip out huge chunks of code, particularly in<BR>
relation to the pre-PostgreSQL 8.0 statistics code (think SELECT<BR>
update_geometry_stats()).<BR>
<BR>
- Rewrite the regression test harness<BR>
The regression test harness is currently written as a shell script,<BR>
which makes running regression tests under Win32 only possible under<BR>
MingW. In order to support an MSVC build, it is intended to re-write the<BR>
regression test script in Perl (which is required to build PostgreSQL<BR>
under MSVC).<BR>
<BR>
<BR>
In terms of support, we hope to be able to maintain the 1.3 branch until<BR>
the end of the 1.3.x series. It may be that some patches/fixes are not<BR>
backpatchable to the 1.3 series, however we will try our best to keep<BR>
both the 1.3 branch and SVN trunk up to date with patches/issues on the<BR>
PostGIS bug tracker.<BR>
<BR>
Apologies for the length of this email, but I hope it gives a good<BR>
indication of where we are planning to go with future developments. I<BR>
don't think there will be too many surprises (see the archives for<BR>
previous posts about dropping support for older PostgreSQL versions),<BR>
but if anyone has any arguments/comments, I would encourage you to reply<BR>
to this thread.<BR>
<BR>
[Note: I have also CC-d to postgis-devel, but please keep any resulting<BR>
discussion on postgis-users]<BR>
<BR>
<BR>
ATB,<BR>
<BR>
Mark.<BR>
<BR>
--<BR>
Mark Cave-Ayland<BR>
Sirius Corporation - The Open Source Experts<BR>
<A HREF="http://www.siriusit.co.uk">http://www.siriusit.co.uk</A><BR>
T: +44 870 608 0063<BR>
_______________________________________________<BR>
postgis-users mailing list<BR>
postgis-users@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>