I agree that breaking changes are inevitable on the main branch, but to Russell's point there are people with deployments of Polaris in production and I think it's unfair to them to simply say "there can be no breaking changes" because there hasn't been a GA release. Breaking changes are inevitable, but should be thoughtfully considered and communicated before merging into main.
"I don't like the design decision" is not a good reason, IMO, to check in a breaking change to an existing API, especially one that is intended to be an extension point for the runtime. I dislike several design decisions that were made previously, but I understand that there were constraints at the time that led to those design decisions - some of which may no longer be relevant or may be reflective of a more specific architecture than what we intend to support. I think a complement to the "assume good intentions" tenet mentioned in the other thread, "respect what came before" is a good tenet to keep in mind when considering design changes. If we assume competence and thoughtfulness of the previous design, then breaking changes ought to come sparingly and only with good reason. Something we should consider is using annotations such as @Experimental to declare APIs that are expected to change very frequently until they stabilize. That gives adopters some warning of things that are unstable. But we should assume anything not annotated as such is expected to be reasonably stable and to change only with clear communication and a reasonable warning period. Another consideration would be having an "internals-only" package with components that are not expected to be depended on publicly and would not contain any extension points. Mike On Fri, Jan 17, 2025 at 10:46 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi > > I think we are mixing breaking changes and stable branch. > > Keeping the main branch stable is super important, I totally agree. > However it’s ok to introduction breaking changes in main compared to other > branches. > By breaking change I mean something that don’t behave the same or has been > removed. > That’s why I proposed to consider 0.9x branch as reference to identify > breaking changes. > > For instance, on ActiveMQ, the main branch (6.2.x) contains breaking > changes compared to 5.18.x or 6.1.x branches. > > So totally agree to keep the main branch clean and stable, but it’s ok to > have breaking changes there, it’s inevitable. > Soon we will have dev and stable branches. Users and developers will use > the branches depending of their need. > > Regards > JB > > Le ven. 17 janv. 2025 à 19:08, Yufei Gu <flyrain...@gmail.com> a écrit : > > > 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 > > > > > > > > > > > > > > >
