> On 9 Dec 2024, at 11:26, Max Yang <maxyang...@gmail.com> wrote:
>
> Welcome to discuss
Hi!
Let’s consider also Clickhouse versioning.
Clickhouse version is “year.release.patch”. Also they add tags “stable” or
“lts” to some releases.
The basic idea is that you have continuous development process not tied to
specific dates. And make branches for the supported versions, which do not
receive new destabilizing features. Adjacent releases must be binary compatible
wrt on-disk data. But we will clearly need a breaking versions with catversion
and wal file magic bump.
This versioning model is more natural for cloud services. It instantly gives a
clue to a customer of how outdated the cluster is.
Also, for a cloud provider it’s good to divide a functionality into tiers:
something that can be removed in future, something that can have api change,
something that is stable and recommended for production use.
I’m mostly proposing this as an alternative for a discussion. I don’t have
strong opinions on which versioning is better. Here you can read more on this
versioning[0].
Thanks!
Best regards, Andrey Borodin.
[0] https://clickhouse.com/docs/en/faq/operations/production
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
For additional commands, e-mail: dev-h...@cloudberry.apache.org
