[postgis-devel] Plan release PostGIS 3.4.0 this weekend

Regina Obe lr at pcorp.us
Fri Aug 11 14:59:51 PDT 2023


> > I'm planning to release 3.4.0 later this weekend and create the
> > stable-3.4 branch today.
> 
> I had not gotten to test this (because of me, not because of postgis!),
but just
> did.
> 
> Nits:
> 
>   NEWS is not written in the form I expect in an RC; dev/beta1/beta2/rc1
>   are separate, and this needs to be folded together.  My take is that
>   in an RC the NEWS is in final form.  Would suggest adjusting to that
>   and cutting rc2, which probably needs very cursory looking at by a
>   few.
> 
Okay I'll shoot out an RC2.  So are you saying I should never have had like 
a separate beta news?  I only wanted to highlight what had changed,
but I'm fine with just keeping the whole thing and just changing the
labeling to 

beta2, RC1, RC2  but content the same.

I think strk was griping about that too.

For the items in beta1, beta2 most of those I wasn't going to bother putting
in 
final release notes because they are either bugs fixed in prior minor
versions
or new interim bugs.  So they seemed important for detailing in
beta1,beta2,rc but not in final release.


>   I think the ANY change is #5092, but it's understated in NEWS and
>   could use a louder statement about the change, and how since it's
>   called under the covers you don't care.  

Yes it's that one. I have rephrased a bit.  Can you see if that is clearer.

> It built ok, and there are two things I was not able to understand:
> 
>   bin/postgis exists now, but I don't see this in NEWS
> 
>   There's a lot of ANY, but still
>      share/postgresql/extension/address_standardizer--1.0--
> ${PKGVERSION}.sql
>   vs for example
>     +share/postgresql/extension/address_standardizer--2.0.0--ANY.sql
>   and it is not clear why

I'll take a closer look at that.  There was a time when address standardizer
didn't follow the versioning of postgis proper so I think that one was to
catch that, but I'll need to look closer


> 
> Running tests, they are all ok until raster which causs pgsql to segfault,
but
> this is longstanding for postgis on NetBSD.
> 
Remind me which raster tests segfaults and which version of GDAL you are
working with?
Do we have this ticketed?  

I know we had an issue way back with a BSD segfaulting reported by a user
because NETCDF was doing something funky causing a OOM Kill.

Thanks,
Regina



More information about the postgis-devel mailing list