Make a new Release 1.5.2

[vitcpp]

The is a quorum to make the new release!

BTW, is it ok to change the version when no schema changes exist? I think, we somehow should change extension version, but I'm interested how other projects deal with it?

P.S. I will prepare necessary commits for the release.

[esabol]

BTW, is it ok to change the version when no schema changes exist?

Surely the answer to that is yes. I think what you are asking though is do we need to add an SQL upgrade script to go from 1.5.1 to 1.5.2 that essentially does nothing? I don't know the answer to that. @df7cb, do you know?

I guess it would be easy enough to test...

I think, we somehow should change extension version, but I'm interested how other projects deal with it?

It's already been changed. It's in https://github.com/postgrespro/pgsphere/blob/master/pg_sphere.control. I'm sure you know that. Just clarifying.

Note: The CI workflows test installing, but they doesn't test an upgrade. This should be a separate issue, I suppose. Doing an upgrade would be difficult to test, I suspect, but maybe not. I guess the workflow could download, compile, and install some old version (the oldest in this repo is 1.2.1) and then have it compile and install the version in the master branch and execute ALTER EXTENSION pg_sphere UPDATE TO 'latest_version_number';. What do you think?

[df7cb]

IMHO extensions should decouple the package version and the SQL version, so no-SQL-changes-releases are possible. For example, the package version could be 1.5.2 and the SQL version 1.5 and whenever that changes, things get bumped to 1.6.(.0).
But since pgsphere is currently not doing that, we should include a no-change SQL script to avoid people being confused.

I meant to blog about this since extensions were invented, but never got to it...

[df7cb]

As for testing upgrades, that is a noble goal, but no one is actually doing that in practice. Even PostgreSQL runs the pg_upgrade tests from the very same version.

If we find a recipe on how to make that work generally, we should publish it so other extensions can pick it up.

[vitcpp]

@df7cb Thankh you for the explanation. How can users identify the exact version of an installed extension if they see only the schema version? The changes in C-code may affect the logic without changes in the schema. In extensions, it is possible to implement a function like _version(), but not sure how it was adopted in postgres.

[vitcpp]

I think we may go further with the new version tag after document deployment fix. I'm working on it now.

[df7cb]

@df7cb Thankh you for the explanation. How can users identify the exact version of an installed extension if they see only the schema version? The changes in C-code may affect the logic without changes in the schema. In extensions, it is possible to implement a function like _version(), but not sure how it was adopted in postgres.

Some extensions like PostGIS provide a xxx_version() function. But imho in most cases that's overkill and users would usually know which version they installed in the operating system.

The question if the new C code works with an older schema version that hasn't been alter extension updated is an independent question...

Let's not worry too much and get this release out 🙂

[vitcpp]

New release 1.5.2 is published.

@esabol, @df7cb, @msdemlei, thank you for your contribution!