Hi Robert, That's fair and I agree: the story will be different when Polaris 1.0.0 will be out. From an end-user, it makes perfect sense.
As the 0.9.x branch exists, from an integrator standpoint (people building something on top of the 0.9.0 branch), we can consider breaking changes compared to the 0.9.0 branch. We don't have to be super strict as it's a 0.9.x (from semver terminology), but, from a community perspective, when possible, we could consider breaking changes between main and 0.9.x branches. I propose to do our best effort: breaking changes are of course totally fine on main, but it's also fair at least to say it's a breaking change compared to 0.9.x (just to clearly state it's a breaking change, without necessarily the need to "fix" it). Regards JB On Fri, Jan 17, 2025 at 9:32 AM Robert Stupp <sn...@snazy.de> wrote: > > 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 >
