Clickhouse: Better release labeling

[iameugenejo]

Use case
To avoid installing releases with unstable behavior, I'd like to request stable release tagging to be revised.

Currently stable builds are released almost every week, and those with critical issues are left labeled as stable even after bugs are identified.

Whenever I want to upgrade to a new clickhouse version because of issues or if newly introduced features are need, I have no idea which version to use but blindly pick the latest available stable release.

And the latest stable release usually doesn't have change log, so I'd need to pick the latest release that has a change log.

Describe the solution you'd like
Solution 1: Don't label every builds that pass the tests to be stable release. Battle test it in production for at least a month and mark it stable.

Solution 2: Remove stable label when any critical issue is identified with the version. If removing the stable label is not possible, update the change log to let users to know about it so they can avoid that release.

Solution 3: Create another label that indicates what the most stable release is out of dozens of stable minor versions.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
There's no way I'd know which is more stable than the other, so no. Testing a release in a test environment doesn't cover every cases.

[den-crane]

Then now the last/current stable will be 18.14.19. Very funny.

[iameugenejo]

Is that tagged or documented as such if that’s an official response? And what is very funny about?

[den-crane]

It's my own opinion. I am just CH user the same as you. Funny because you proposed a solution which will make everything even worse.

[iameugenejo]

Can you elaborate on that? Why do you think everything will be worse with any of the suggestions? And I would love to know if you have any better solution because I’m having quite a trouble with current situation.

[den-crane]

Solution 1: Don't label every builds that pass the tests to be stable release.
Battle test it in production for at least a month and mark it stable.

Nobody will install test version in production. It's nonsense.

Solution 2: Remove stable label when any critical issue is identified with the version.

Most of stable versions have critical issues. The could be critical for you but not for me.

The solution for you is very simple. Just test stable for 6 months at your stage.
I advice you to start with 19.4.3.11 (basing on my memory: I remember all CH github issues and I read millions of messages in russian and en telegram ch chats).

[iameugenejo]

Nobody will install test version in production. It's nonsense.

I didn't mention all releases should be labeled test version. Just leave it as a version without stable tag?

Most of stable versions have critical issues. The could be critical for you but not for me.

Maybe enough critical issues warrant a removal of stable label?

The solution for you is very simple. Just test stable for 6 months at your stage

This company I work for can't afford to spend so much money to have a staging environment to catch a bug that would happen when the throughput of ingestion is over 10 billion rows a day. So maybe it's simple for you with so much money, but not for this company with so little.

I remember all CH github issues and I read millions of messages in russian and en telegram ch chats

Maybe it's more helpful if you made a web site that lists each clickhouse versions and all the github issues related to them, and also millions of activities in russian and en chats quantified as such that would indicate which "stable" version of clickhouse deserves a stable tag to be dropped.

[alex-zaitsev]

Originally, Yandex marked release 'stable' as soon as it is installed for Yandex.Metrica. Now they wait a bit for community feedback first I guess. In general, it makes sense to use the latest minor version from the previous major one. E.g., if latest release is 19.13.2 now, the most tested and bugfixed is 19.11.7 (19.12 has not been released). But sometimes minor releases introduce their own problems, though this is uncommon.

The last stable version without critical bugs from Altinity standpoint was 18.14.19. This is 8 months ago. https://www.altinity.com/blog/tag/Releases

Nevertheless, 19.x releases are used quite a lot in production, so you may never step to any problem in your environment.

List of known issues would be good to have, but there is no bandwidth to maintain it. This is an open source project after all. If you would like to do that for the community sake, that would be great.

[iameugenejo]

Thank you for more helpful comment, @alex-zaitsev. It’s helpful that you linked the Altinity blog for the reference. I’ll keep an eye on that blog.

[alexey-milovidov]

Solved #8285