Hi Andrey, Good to see you!!! Yes, we need to add some checks in codes to let the program automatically discover incompatible issues. As for the issue of functional classification, it can be added with corresponding tags during code review, and the document can be associated with this information when published?
On Mon, Dec 9, 2024 at 5:01 PM Andrey M. Borodin <x4...@yandex-team.ru> wrote: > > > > 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 > >
