I'm not sure it is so clear cut, while we may say it's a work in progress there are a lot of users of the current codebase at least from our perspective. While this shouldn't be a blocker for every change it definitely cannot be ignored wholesale. The current branch *is* in use in production and I don't think it's fair to other contributors to just ignore that when making decisions. We and our users are parts of the community as well and while this doesn't give us a monopoly on decision making it also doesn't remove our voice from decision making.
I think this is also relevant to the discussion of "-1's" being infrequent. One of the issues with this policy is that any commit which breaks something that already was merged is essentially a -1 to what happened before, just after the fact. For example, if I decide something is a String and get it merged, and then someone else decides that same field should be an int and attempts to merge that. The +1's on the second PR are essentially post review -1's on the first PR. This is not to say that we can't ever move forward but it should be noted that all breaking changes are essentially vetoes of a past decision so they require some reflection. On Fri, Jan 17, 2025 at 4:35 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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 > > >
