Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3365 closed defect (fixed)

Remove code for unsupported GEOS versions

Reported by: dbaston Owned by: pramsey
Priority: medium Milestone: PostGIS 2.3.0
Component: postgis Version: master
Keywords: Cc:

Description

Trunk will only build with GEOS ≥ 3.3.0, but there are several areas where conditional compilation provides alternate code for earlier versions.

Change History (8)

comment:1 by dbaston, 9 years ago

pramsey - I can put together a patch for this, unless there is a reason not to. Does PostGIS still support builds that omit GEOS entirely?

comment:2 by robe, 9 years ago

No we don't support compiling PostGIS without GEOS anymore. That went out like in 1.0 days I think.

I think pramsey is proposing gettting rid of all the cruft that checks for lower than GEOS 3.3.0 rather than trying to get it work for lower than 3.3.0.

getting rid of cruft would be my preferred direction.

Last edited 9 years ago by robe (previous) (diff)

comment:3 by dbaston, 9 years ago

Great, so it sounds like anything that checks for GEOS < 3.3 can be removed entirely. Let me know if I should proceed with this. Maybe a separate discussion is whether PostGIS 2.3 will require 3.4 or even 3.5?

comment:4 by robe, 9 years ago

dbaston - we usually bring this up to vote in postgis-dev, might be good to bring it up now and get it out of the way early.

I'm usually the evil one saying down with history and strk saying — oh we must support GEOS 2.2 - think of all those people stuck on GEOS 2.2 and then we settle on one version less than what I want and at least one version greater than he wants as a requirement.

I would like 2.3 to require 3.5. For several reasons

1) There is a lot of fixes that just never get backported to older geos just cause they are too much hassle. So only serious crashers do. The more people are stuck using the old geos the more burden of backporting fixes or people just getting annoyed. Besides GEOS versions can coexist and a newer GEOS from as far back as I can recall is always backward compatible with older GEOS minor.

2) PostGIS 2.3 is probably like a year away (IF we are lucky), so by that time, GEOS 3.6 might be out already or close to being out.

3) We'll have ST_Voronoi which will be yet another function requiring 3.5

4) I think most package maintainers are shipping 2.2 with GEOS 3.5 already — thanks package maintainers :).

comment:5 by dbaston, 9 years ago

Pull request at https://github.com/postgis/postgis/pull/77

Any objections to me merging it?

comment:6 by robe, 9 years ago

no objections from me. I'd go for it. 3.3 is so ancient that I don't know why we would bother with it in 2.3

comment:7 by dbaston, 9 years ago

Resolution: fixed
Status: newclosed

Applied to trunk at r14466. Let's open a new ticket if 3.5 will be required for 2.3. It seems like a reasonable requirement to me.

comment:8 by robe, 9 years ago

Seems reasonable to me too since now we have at least 3 functions that require 3.5. In 2.2 3.5 hadn't quite been released yet. Should first raise for a vote on Dev first though.

Note: See TracTickets for help on using tickets.