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
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, changin
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.
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
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
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
