I’m really concerned about this being mentioned on the dev list. Open-source projects thrive on the trust of users and developers, and keeping the main branch stable is a big part of that. This is especially important since Polaris hasn’t had an official release yet. People rely on the main branch for PoCs and even for production work. If we keep breaking it—or leave it broken for too long—it’s going to drive serious users and developers away. Trust might seem like a small thing in the moment, but in the long run, it’s critical and not something we can afford to lose.
Yufei On Fri, Jan 17, 2025 at 9:50 AM Russell Spitzer <russell.spit...@gmail.com> wrote: > 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 > > > > > >
