Hi JB, thanks for outlining that distinction. I think you're right that these are two different topics and that we run the risk of conflating them.
Below, I'll use the term "regression" to refer to changes to a branch (e.g. main) that may make older usage of that branch break. For example, changing a method signature in a way that may make callers break. Even once we have branches, regressions should be looked at carefully. In my opinion you are right that it's "ok" to have them sometimes, but it is not something we should do lightly. As Russel notes, if a variable is currently a String in main and it received 10 +1s initially, a PR which changes it to an Int has an implicit 10 -1s. I would be cautious merging any change that receives a significant number of -1s, even if they are not the majority. 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 > > > > > > > > > > > > > > >
