v10.1.2 PATCH release

[steve-chavez]

v10.1.1 is currently not stable for production as mentioned on #2638 (comment).

We'll need to make a v10.1.2 that includes some fixes.

Included fixes:

• v10: Wrong query on M2M relationship when using RPC #2565, Fix bad M2M embedding on RPC cb99270
• Add hint for similar function parameter names when they don't match #2575, Replace misleading error message when no function is found with a hint containing functions/parameters names suggestions 9e56721
• Clarify error messages for functions #2582, Clarify error messages for functions aecc53d
• reload the schema cache error message is misleading #2569, Replace misleading error message when no relationship is found with a hint containing parent/child names suggestions 5a660e0
• OpenAPI generated specs do not support type: array, and use format: ARRAY instead #1405, Add the required OpenAPI items object when the parameter is an array 1f69757
• Missing Swagger Prefer Option Preventing Upserts via Swagger UI #2592, Add upsert headers for POST requests to the OpenAPI output 4ddd5b4
• fix: FK pointing to VIEW instead of TABLE in OpenAPI output #2623, FK pointing to VIEW instead of TABLE in OpenAPI output 775c006
• PostgreSQL Authentication failure not considered as fatal #2622, Consider any PostgreSQL authentication failure as fatal and exit immediately 8aa7908
• NOTIFY doesn't reload the catalog cache #2620, Fix NOTIFY pgrst not reloading the db connections catalog cache 7874bee

The only critical fix is really 7874bee, so if some fixes turn out to be hard to merge(due to refactors and dependency to other commits) we can leave them for v11.

[steve-chavez]

I realize this does cause an issue again for users of pre-releases, as mentioned on #2296 (comment)

The out-of-order 9.0.1 patch release causes our version numbers for pre-releases to break the "higher version number means more recent" promise.

I think a solution for this will be reserving a minor for pre-releases.

So if we had a v10.2.1.20221215 instead of a v10.1.1.20221215 releasing a v10.1.2 would not break the above promise.

And then if we want to go for a minor release, we'd have to jump two numbers, from v10.1 to v10.3, I think this is fine. A major v11 will work as well.

Will make this fix in the postgrest-release command.

cc @wolfgangwalther

---

Just to make this clearer:

• When having a v10.0.0 a pre-release will be v10.1.0.20221215 - next minor would be v10.2.0 - a patch version can be v10.0.1
• When having a v10.2.0 a pre-release will be v10.3.0.20221215 - next minor would be v10.4.0 - a patch version can be v10.2.1

Writing this made me realize that if we add a feature then we have to bump the minor of the pre-release. If we make a fix we can keep the minor of the pre-release.

---

Edit

See https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning

Developers may choose to jump multiple minor versions at a time to indicate that significant features have been added, but are not enough to warrant incrementing a major version number; for example, Internet Explorer 5 from 5.1 to 5.5 or Adobe Photoshop 5 to 5.5. This may be done to emphasize the value of the upgrade to the software user or, as in Adobe's case, to represent a release halfway between major versions

So it's good to jump multiple minor versions.

[wolfgangwalther]

Just to make this clearer:

* When having a v10.0.0 a pre-release will be v10.1.0.20221215 - next minor would be v10.2.0 - a patch version can be v10.1.1

* When having a v10.2.0 a pre-release will be v10.3.0.20221215 - next minor would be v10.4.0 - a patch version can be v10.2.1

Writing this made me realize that if we add a feature then we have to bump the minor of the pre-release. If we make a fix we can keep the minor of the pre-release.

Hm. This essentially means, that odd minors will be pre-releases and even minors will be stable releases, right?

This is basically the same thing that for example nodejs does - only that they do it with major releases: Only even major releases are considered stable. Odd major releases are considered experimental.

What if we instead do the same?

We would not need the fourth version component. We'd just release 11.0.0 as a pre-release. As soon as we release a bug fix, we bump to 11.0.1. As soon as we commit a new feature, we bump to 11.1.0. And we do the same for breaking changes, just bumping minor and patch respectively.

At a given time, when we are confident about stability, we bump to v12, which is then considered stable again.

We'd still try to give us a little bit of time after a major version bump before merging new features/breaking changes. This would allow us to release a possible bugfix release without branching off.

You'd still have the freedom to go back and release patch versions for the latest stable version. It happened twice already, so I don't think we can continue to pretend it will never happen.

I think this would be a lot more transparent compared to hiding the same within minor releases and the fourth version component.

[steve-chavez]

Sorry for the late reply here.

This is basically the same thing that for example nodejs does - only that they do it with major releases: Only even major releases are considered stable. Odd major releases are considered experimental.
What if we instead do the same?

I didn't know that, it's an interesting idea. But that would basically break semver right? Seems risky as we have been committing to semver and it will be surprising to users that a new version causes a breakage.

As soon as we commit a new feature, we bump to 11.1.0.

That could be an option, just releasing more frequently. The downside is that that could cause something like "notification fatigue"(users will then ignore updates). Personally, I prefer the way PostgreSQL does releases, once a year I can keep up with learning the new stuff. That might be too extreme for us, but you get the idea.

You'd still have the freedom to go back and release patch versions for the latest stable version. It happened twice already, so I don't think we can continue to pretend it will never happen.

Yeah, true. Right now I'm willing to put in the work and create branches from time to time, rebase the fixes and do releases there.

Another option could also be to never do releases off the main branch, only on other branches(like rel-). I've seen projects(like pgx) that commit to a devel branch(not main) a do the releases on other branches.