[postgis-devel] Vote on Merging postgis and raster installsandwhen

[Paragon Corporation]

> I'll note that as of now, logic dictates that we have *no* 
> backward compatibility, because (a) topology should be a 
> default build component and (b) topology requires GEOS >= 
> 3.3.2 (Arg!!! minor version requirement!) and (c) that 
> version of GEOS isn't even released yet!


Well technically it depends on 3.3.2 because parts of it would be buggy
without it, but API wise it doesn't.

I would like to make it a rule at some point (like make it a rule now), that
if ever we have a function in PostGIS that requires
said version for it to work, we should at the very least make that GEOS
version a minimal (with the option of forcing the user
explicitly allow a lower version with a nasty notice that are they aware
what they are disabling ? ).

Here is my main issue -- If you are a packager, and you like to play it on
the safe side which I know for a fact many departments
have it a rule that they will always stay one version behind unless good
reason not to.  Even I do that if I'm not familiar with the library.

They'll see a 3.3.2 is current.

"Hmm lets do 3.2.3 cause there are probably bugs in 3.3 we'll wait till 3.4
before we go to 3.3"

So anyway the package manager as a general rule chooses one minor version
before the latest version.  Low and behold the
poor PostGIS user has to put up with 3-6 functions being disabled probably
much of the reason they wanted to do 2.0.0 in the first place.

ST_UnaryUnion, ST_RelateMatch, ST_Snap, ST_SharedPaths, ST_Node,
ST_MakeValid

all require 3.3 or above and ST_MakeValid is a big reason a lot of people
are excited about 2.0.0

Thanks,
Regina