-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
docs: describe the process for making breaking changes #2103
Conversation
👍 I think we should also have a section like the Node.js project : When Breaking Changes Actually Break Things |
Thank you for the link, I was not aware of this resource. To be honest, I don't know how to apply it to LoopBack. We don't keep |
I was thinking about the case where some unplanned breaking changes where pushed in master and published in NPM and what to do about those (revert ? retroactively label them as breaking changes ? ...). |
The master branch is configured as protected on GitHub, only repo admins can push to master directly. Everybody else is required to open a pull request, this is enforced by GitHub at git level. Process-wise, every change should go through a pull request review, which should hopefully catch them. Of course, there is always a possibility that a breaking change is unnoticed by PR reviewers and gets landed on master.
Awesome! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I believe it's "backward compatibility" instead of "backwards compatibility".
1aa12e3
to
970a4a1
Compare
In the light of #2078, which is likely to introduce a semver-major change, I feel it's important to have some documentation (a kind of a check-list) capturing all steps to take before making the actual semver-major release.
@strongloop/loopback-maintainers please take a look and let me know what you think about my proposal.
Checklist
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated