Make a new Release 1.5.1

[vitcpp]

Dear All,

I think, it is the time for a new release. Do you have any objections?

[esabol]

Sounds good to me. Thank you, @vitcpp !

[esabol]

Just out of curiosity, how much time typically between the pre-release and when it becomes the official release?

[vitcpp]

@esabol It is up to us. I apologize, I delayed the release due to some circumstances (lots of other work). I just wanted to do some more testing of upgrade before creating a new release. I'm going to do it for 1 - 2 days.

[esabol]

No need to apologize. It's a sensible course of action. May I ask a favor? When the pre-release becomes an official release, could you post a message here? I'm afraid GitHub will not send another notification. That has happened for me in the past with pre-releases.

[vitcpp]

@esabol Yes, sure. I will do that.

[vitcpp]

Some problems were found in 1.5.0. The new release candidate version is 1.5.1.

[vitcpp]

Dear All,

I've created a new release candidate tag 1.5.1-rc1. The upgrage from 1.4.2 to 1.5.1 seems to go smoothly - KNN query time is significantly decreased. I put this tag on display for public testing for those who is interested. In a couple of days I plan to issue a new release 1.5.1 if no bugs are found.

If no objections, I will remove 1.5.0 release candidate tag from the list of releases.

I think, I'm about to finalise the steps of the release process:

1. Once the decision to issue a new release is made, create a tag with -rc1 suffix (example: 1.5.1-rc1).
2. Put this tag on display for testing purposes by creating a new release candidate in the Releases section.
3. Wait for feedback from the community (one week may be enough).
4. If the release candidate tag is ok, create a new tag without -rc1 suffix and issue the new release with this tag. The release process is completed here.
5. In case of reported bugs, fix the bugs without changing the release version. Once completed, create a new tag with suffix -rc2 like 1.5.1-rc2. Remove the current release candidate record from the Releases section. Go to step 2.

What I'm concerned - is it ok to remove release candidates from the Release section?

Once agreed, I will put this description to README.md or CONTRIBUTING.md.

[vitcpp]

Dear All,

The Release 1.5.1 is published. Thank you for all your interest and contribution.

[vitcpp]

@esabol The new release is published. Thank you very much for your contribution!

[vitcpp]

Closed as completed.

[df7cb]

The Debian builds are happy as well, thanks!

[esabol]

I just upgraded our servers from 1.4.2 to 1.5.1. I was a bit surprised that the tests all passed before I actually executed ALTER EXTENSION pg_sphere UPDATE TO '1.5.1'; (but after I make installed). Is that to be expected?

[vitcpp]

@esabol Not sure about it. Could you please provide some details? How did you run the tests?

[esabol]

I'm not doing anything unusual, @vitcpp.

make USE_HEALPIX=0
make USE_HEALPIX=0 install
env PGUSER=postgres make USE_HEALPIX=0 installcheck
env PGUSER=postgres make USE_HEALPIX=0 test
env PGUSER=postgres make USE_HEALPIX=0 crushtest

[vitcpp]

@esabol, I think, everything is ok. The extension is bound to a database, not to the cluster as a whole. The target installcheck works with the running cluster. It creates and uses contrib_regression database for testing purposes. All the tests are running with this database. The first test init.sql executes CREATE EXTENSION statement which loads the extension in the current database (contrib_regression). Once you've installed a new version of pg_sphere, the create extension statement picks the new version. I guess, your other databases are untouched by tests, so, they may contain pgsphere schemas of a previous version. I think, it explains why installcheck works without errors at your side. Please, let me know if you need more clarification.

[esabol]

OK. Thanks for the explanation. That makes sense. Not sure why I suddenly thought otherwise!