Repository navigation
Conversation
| We follow [semantic versioning](https://semver.org). | ||
| Breaking changes increase the major version, backwards-compatible changes (typically new additions) only increase the minor version, and bug fixes (including changes to the comments) only increase the patch level. | ||
| (An example of a breaking change is when `hardware.inc` 4.0 updated its syntax for compatibility with RGBDS 0.5.0, breaking compatibility with older RGBDS versions.) | ||
| See [CONTRIBUTING.md](CONTRIBUTING.md) for how to contribute changes and how releases are made. |
There was a problem hiding this comment.
maybe it's still worth mention in the README that master isn't stable and to use a tagged version
There was a problem hiding this comment.
If we want to mention it in the README, I think it would be more relevant for users than contributors. How about a new sentence at the top: "The latest version of hardware.inc is v6.0.0.", linking to the tagged release. And the CONTRIBUTING.md instructions should say to update this file as well when releasing a new version.
| Breaking changes for the new major version are merged into this branch through pull requests targeting it, instead of `master`. | ||
| Non-breaking changes keep going to `master` as usual; merge `master` into the version branch periodically to keep it up to date. | ||
| 2. **Release a candidate.** | ||
| When the version branch is ready, update `HARDWARE_INC_VERSION` and `HISTORY.md` on it for the RC version (e.g. `6.0.0-rc1`). |
There was a problem hiding this comment.
is this needed already for the RCs?
There was a problem hiding this comment.
Yes, when we published v6.0.0-rc1, it had def HARDWARE_INC_VERSION equs "6.0.0" (ce32c88). That's appropriate so anyone using rev_Check_hardware_inc 5 would not pass it, because the RC already has breaking changes.
No description provided.