RFC: automated version numbering and publishing
- With 60+ independently versioned packages across the PubSweet ecosystem, keeping track of breaking changes in order to adhere to semver will be impossible without tooling assistance.
- When a change to a dependency has been merged but not yet published, it is hard to work on another feature because the change in the dependent package cannot yet be merged and yet the change in the dependency is already present in master of the dependency.
Scenario illustrating problem 2
- Make a change to
- Submit MR for B
- A is blocked until B is published as the tests will fail without it
- Start another feature with changes to
- B is merged
- Rebase D onto
- Your local setup is now broken as C has no knowledge of A but is presented with the incompatible changes from B which are now in
- Lerna includes a
--conventional-commitsflag which analyses the commit messages for each package and bumps the version numbers according to some rules. This shifts the responsibility for tracking breaking changes from the person doing the publishing (who may have several hundred commits to consider) to the person doing the committing who has only one.
- With this in place, problem 2 can be solved by configuring CI to publish to npm and push the updated version numbers back to the repo as demonstrated here.
- If we do not wish to adopt conventional commits at this time, there is another approach to problem 2 using Lerna's
--canaryflag. This would allow CI to publish prerelease versions on every merge while still requiring human input to publish final versions.
- Automated version numbers mean letting go of sentimental versioning tied to milestones. Version 39.1.0 will be here before you know it.