[postgis-devel] Plan release PostGIS 3.4.0 this weekend

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>> > 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 it is ok to have separate content for each alpha/beta because
those are the changes from the last release to the alpha pseudo-release.

But, once we are at rc1, it should be "if this were the release, would
you be happy", modulo the version number changing.  And, a 3.4.0 release
should have NEWS relative to 3.3, with no mention of alpha/beta/rc.

> I think strk was griping about that too.

I am guessing strk and I are saying the same thing.  After all back in
the day we attended Church of the GNU Coding Conventions summer camp
together.

> 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.

They are important in alpha/beta.   But once you are at rc, you really
mean "if there is nothing wrong we can release this" so it should be
squashed already.

Yes, things fixed that were bugs earlier in this branch should just be
omitted in the release NEWS.  They have effectively been rebased out,
even if they are in history.

Your squashing looks good.  I'd drop the rc2 from the file now, so you
won't forget to change it later.  Of course NEWS in git is for that
commit.

>>   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.

Yes, it gives the hint that between "reduce" and "provide ANY" to a
person looking at the diff of installed files, that this is indeed
upstream intent and not a bug that happens to trigger on my system.
That's what I was looking for.

>> 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

bin/postgis being installed and what it does is worth a 2-line entry in
"new features" 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

That could well be.  Not saying it's wrong, just that as I read the diff
looking for trouble, actually in postgis normally, and things that
trigger in my environment, this jumped out at me as maybe not intended.

>> 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 think it's almost any, and I am behind:  gdal-lib-3.5.3nb3

I am not sure it is ticketed, because until I dig in more there is no
real reason to believe it is a postgis bug.

> 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.

Ah, interesting concept.   NetBSD does tend to have lower limits.