Hey guys,
since there are already some other discussions going on, I want to also
start one about breaking changes.
IMHO a breaking change is a change that (not 100% formally correct:)
requires action from the user and/or removes functionality and/or
changes public API and/or the configuration in a new released version
compared to an older released version. (Major version requirement in
semver terminology.)
Given that there is no Polaris production-grade GA release yet, there
can be no breaking changes. But even if, semver says that this is
(mostly) fine in 0.x.x releases.
Everything on the main branch in https://github.com/apache/polaris repo
work in progress. I think we have an agreement on that it is not yet as
complete as we want it nor production-ready. Especially the main branch
is not considered stable. IMHO the main branch should never be
considered stable.
I do not mind if people check out the code, try out Polaris' and
experiment with the current state of development. That's completely fine
and appreciated.
But I think we should be clear on the assumption that only released
versions labeled as "GA"/"production ready" are supported. We cannot
guarantee that something from random commit A will ever work with
something from random commit B. We cannot guarantee backwards/forwards
compatibility across individual Git commits - only across released versions.
Side note: Ideally I'd like to support rolling-upgrades - and I think
that this is doable.
Thoughts?
--
Robert Stupp
@snazy
