[geos-devel] PSC Vote release GEOS 3.5.0

[Paragon Corporation]

With what Greg Troxel has said already, I say we just go for a GEOS 3.5.0
release and if people have issues, we'll fix and cut a GEOS 3.5.1.

So 3 PSC have voted - Paul gave his +1,  I gave my +1, 

Strk -- as I recall, you said okay to a release, if I closed all the
tickets.  Paul is willing to do the release if you aren't. 
I'm going to take this -
https://lists.osgeo.org/pipermail/geos-devel/2015-August/007208.html  (as a
+1 from you)

Remaining PSC members - please speak now or forever hold your peace -
https://trac.osgeo.org/geos/wiki/PSC

Package maintainers please stand by to test.

And let's get the show on the road!


Thanks,
Regina
---------------------- GREG's NOTE BELOW

> On Tue, Aug 04, 2015 at 08:15:02AM -0400, Paragon Corporation wrote:
>> > Did anyone respond to the call-for-testing on geos lists ?
>> What call?  People, especially package maintainers don't like testing
stuff
>> unless it's in an unchanging tar ball.
>
> Uhm, I though you sent a call for testing, evidently you didn't.
> Would tagging an RC1 give packagers an unchanging tarball ?

I actually did run tests, but I made my own tarball.  I think I posted a
note about it, but it seemed to build/run/check ok on NetBSD 6 i386.

As a package maintainer, what I'd like for testing is a distfile that's
just like what would be released, except with a different version.  And
of course it should unpack to a name consistent with the tarball and
version.  Basically the output of "make dist", and in cases where that
really is how releases are generated, it's easy enough to do myself.

The other big thing for packaging is that once a file is published with
a version number, it can be withdrawn, but no file with the same name
and different contents should be published.  The reason is that
packaging systems record checksums to guard against distfile partial
fetches and tampering.   So "fixing" a distfile is indistinguishable
>From tampering.  If that's needed, just increase the point version
(e.g. 3.5.1) and people can update.   Updating pain is proportional to
structural changes and the amount of code that newly doesn't work with
compilers, etc., plus about 3 minutes of constant time, so trivial fixes
like this take only the few minutes.
---------------------------------------------------------------------