Put WARNING in PostGIS missing functionality if

[robe]

If someone happens to compile PostGIS without certain libraries/versions even though we allow it e.g. GDAL 1.7+, GEOS 3.3+

We should put in a big warning that they will be missing functionality.

Maybe with a URL to our matrix of reasons. Still need to put in GDAL dependency in matrix. LibXML I didn't bother since can't compile without it and we aren't using any functionality found in newer versions.

http://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS

[mcayland]

We've always been fairly aggresive about using new versions of various libraries when required, so I'm tempted to suggest GEOS 3.3/GDAL 1.7 as minimum versions for trunk to minimise multiple codepaths. The amount of things that are changing for 2.0 will probably make a version upgrade seem easy in comparison

[strk]

We haven't _always_ been aggressive. I like building software to be as easy as it can be for a starter, and allow incremental improvements in a second step.

People that just want to take a look should be allowed to build postgis and only postgis against the packages their distribution provide them.

I suggested the WARNING idea to make it clearer to the builder that she's building a suboptimal version of postgis.

[mcayland]

Well building the software is generally done by packagers rather than end users so I'm not too concerned about that argument.

We spent a lot of time in the 1.4/1.5 timeframe mandating certains versions for two reasons: firstly, it eliminated a lot of #if …. #endif version-dependent code to make the code easier to read, and secondly it prevented issues where developers running different versions of libraries would commit code that would break for other people because they didn't test all combinations of optional dependencies during regression.

Given that amount of manpower we have as a project, I think that bumping the minimum versions is the best option in terms of giving the users a consistent experience whilst also making life easier for developers.

[robe]

Yap that was the compromise strk and I worked out. I'm more on your side Mark — though. As a user of packages and having clients that I push to just use packages becuase its a much easier install experience, I'm often frustrated that the packager didn't package all the goods needed to experience a full PostGIS experience because they didn't know using the minimal versions of things would give you a half-assed PostGIS experience.

I do see strk's point too — is it better to have a some not as optimal PostGIS or not to have a PostGIS at all? My primary concern is package managers and pushing them to take the effort to package a fully functional PostGIS package, but I also agree with you Mark, it adds an undue burden regression testing all those permutations of GEOS in particular.

[mcayland]

Replying to robe:

I'm often frustrated that the packager didn't package all the goods needed to experience a full PostGIS experience because they didn't know using the minimal versions of things would give you a half-assed PostGIS experience.

I think this is the key thing for me, especially that the end-user would never get to see the compile-time warning anyway. All they would know is that compared to someone else's installation, their version of PostGIS throws errors when trying to run the same query and so they will give up and look for something else.

[robe]

Not to mention the 3rd party software that uses PostGIS as a back-end (which there are more of now) knowing that if a person is running X version of PostGIS, they can rely on a consistent same set of functions and not have to penalize other users by targeting the lowest common denominator of PostGIS 2.0.0 functionality.

[pramsey]

OK, in at r9081