[postgis-devel] PSC vote Request: Make Geos 3.5 the default in PostGIS 2.2

[Greg Troxel]

"Paragon Corporation" <lr at pcorp.us> writes:

> This is just for PostGIS 2.2 and the plan is since some very popular
> functions in PostGIS 2.2 will not work without GEOS 3.5, then GEOS 3.5 WILL
> BE released before or very near PostGIS 2.2.  
> Just as PostGIS 2.2 has to be released before or very near release of
> PostgreSQL 9.5

I can see the point, but that's tricky business, as history in general
has shown that projects have gotten into a bind between waiting for
releases that do not come and making releases.

> strk -- you know that right that you have to pull the plug on GEOS 3.5.0
> before PostGIS 2.2.0 can go out the door.

So it seems to me that if postgis is having this discussion it's a clue
that GEOS 3.5.0 is overdue and the fix is to work on that.   (I realize
that's other people's effort and probably easier said than done.)

> Now regarding the 6-months running -- wouldn't you have the same issue with
> using PostGIS 2.2 right out of the gate? If you do, you'd probably wait for
> 6-months for that too
> So it would be a non-issue.

Not entirely - this is the big disconnect between people who work on
projects and packaging systems, which I realize is not clear to those
who don't do packaging.

First, my view is that almost all uses of a successful project is via
some packging system.  This is of course totally the opposite of how all
contributions are made - those people all build from git/svn, and often
build close dependencies from source too.

Packaging systems differ, but I'm using pkgsrc as my example because I'm
most familiar.  A package is updated to the new version when someone
both thinks it is prudent and gets around to it.  Thinking it prudent is
about making a judgement that users (including users of depending
packages who have no idea the package even exists) who have no idea
what's going on with the update are better served by getting the new
version.  In pkgsrc, there is then a stable branch every 3 months.  So
it's a fair expectation (not always met) that a new release will be
available in the current stable branch if it's been really recommended
to upgrade for 6 months.

That said, you have a point about a new postgis and a new geos; the
packaging system would just hold off on postgis until geos was updated.

> Same thing with PostgreSQL 9.5 - some key features in 2.2 will only be
> available to PostgreSQL 9.5 users.

But does that mean that a packaging system should refuse to build 2.2
against 9.3?

> I'm not saying we should require 3.5, I'm just saying that if you've got 10
> packages to worry about,  normally if you compile stuff and it gives no
> warning and all tests pass, you think you have all the great functionality
> of the new release,
> And my point is that without 3.5, you are missing a couple of key pieces
> that make PostGIS 2.2 worthwhile to even consider over PostGIS 2.1, so you
> should be warned so you don't get users complaining about how this function
> throws
>
> "Requires GEOS 3.5.0" 
>
> and it's a pain to try to do something about it.

I see your point, but the real problem is not what postgis does.  It's
that 3.5.0 is not released.

I think a "may not depend on unreleased versions" rule avoids the
downstream problems when expectations are not met, which is why I
think it's important to follow that rule.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150602/71371b3b/attachment.sig>