[postgis-devel] PostGIS 3.3.0alpha1 released

Regina Obe lr at pcorp.us
Tue May 24 16:35:46 PDT 2022


> > On May 23, 2022, at 9:43 PM, Regina Obe <lr at pcorp.us> wrote:
> >
> > Speaking of which, pramsey, are you planning to do this in 3.3.0?
> 
> If people think it's critical. It's not really my Zen, but ...
[Regina Obe] 
It's not critical for me.  I'm more annoyed by the bazillion files than I am
about the size of the files.
Though reducing my package below 100MB like it used to be would be nice.


> I was wondering, as I worked on a side-project extension (where I don't
put
> any version information on the .so file at all, and only version the
scripts down
> to the minor level), why we push the patch number down into our scripts. I
> guess for any script-level functionality (like the old concave hull, and
some
> other stuff) it's the only way to get fixes in place. But otherwise it's
really quite
> pointless, since we keep the SQL API static across patch releases. And
thus we
> get all those extra files, etc, etc, etc.
> 
> Feels like an impossible change, but on the other hand, we're a pretty
staid
> and slow moving project at this point.
> 
> P
On the postgis, address_standardizer, and postgis_sfcgal extensions part  we
could in theory live without the patch in our scripts.

postgis_tiger_geocoder I've in the past put changes in a micro e.g fixes to
tiger loading.  But I can shake myself of that habit.
postgis_topology and postgis_raster I think there is a lot more that changes
in micros.  That might be a bit harder.

It would mean we absolutely can't make script changes in micros, like
patching up things that aren't schema qualified, changing costs to fix a
bug, 
and changing our maintenance functions.  Which of course means being more
disciplined about it.  Something I'm not that good at, but trying to be
better.

But I'm a +1 for moving toward that direction (perhaps deciding which
extensions we can safely or not safely make that policy on). Whether we can
make it happen in 3.3.0 is doable, but maybe better to target for 3.4.0 so
we don't feel so rushed about it.

Thanks,
Regina



More information about the postgis-devel mailing list