-
Notifications
You must be signed in to change notification settings - Fork 540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking changes policy #1424
Comments
Overall, this LGTM. I would love to have this text in What do we do with bzlmod, which is still beta and may see more breaking? Do we keep the same behaviour? |
Good question. For things considered beta, I think we should record that an incompatible change has occurred (in commit description and changelog), but not require an opt-in toggle. I expect we'll have a similar situation with Phillip's work redoing how the pip integration works (that it'll span multiple releases to uncover bugs and reach feature parity). And yes, this policy will go in contributing.md, alongside the commit description guidelines. (I just wanted to start with an issue for discussion purposes.) |
Update from our maintainer's meeting: we'll go with a 3 step process.
Note the |
This largely covers how to introduce a breaking change. It also attempts to clarify what is or isn't a breaking change. Closes bazelbuild#1424
This largely covers how to introduce a breaking change. It also attempts to clarify what is or isn't a breaking change. Closes bazelbuild#1424
This largely covers how to introduce a breaking change. It also attempts to clarify what is or isn't a breaking change. Closes bazelbuild#1424
This largely covers how to introduce a breaking change. It also attempts to clarify what is or isn't a breaking change. Closes bazelbuild#1424
As part of establishing a 1.0 release (#1361), I want to write down our policy and process for breaking changes.
The basic policy and procedure I'm leaning towards is something like:
The basic idea is: it's easier to handle breaking changes when you can incrementally upgrade a code base. e.g., upgrade the dependency version N, update apis to the new version's requirements, then upgrade the dependency to N+1.
I'm not keen on a date-based scheme (e.g. an incompatible change must retain a compatible option for 6 months); I'd rather just use version releases.
I'm torn about what happens after that, though. I see two approaches:
The text was updated successfully, but these errors were encountered: