RFC: automated version numbering and publishing

Problem statement

1. 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.
2. 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

1. Make a change to xpub (A) and @pubsweet/ui (B)
2. Submit MR for B
3. A is blocked until B is published as the tests will fail without it
4. Start another feature with changes to xpub (C) and @pubsweet/ui (D)
5. B is merged
6. Rebase D onto master
7. 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 master

Proposed solutions

1. Lerna includes a --conventional-commits flag 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.
2. 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.
3. If we do not wish to adopt conventional commits at this time, there is another approach to problem 2 using Lerna's --canary flag. This would allow CI to publish prerelease versions on every merge while still requiring human input to publish final versions.

Issues

• Automated version numbers mean letting go of sentimental versioning tied to milestones. Version 39.1.0 will be here before you know it.

Sam pointed out another potential solution to problem 2 which is to not work on master and instead branch from the tag that represents the published version of the dependency which is listed in package.json. That way the feature branch C doesn't see the incompatible changes in B. There's a potential for more merge conflicts but it shouldn't be too bad, provided features branches are not kept open too long.

From Dev WG meet of Wed 17 Jan 2017:

There were questions about:

1. Do we need to validate commit messages to fit the format?
2. What happens if a commit message doesn't fit the format?
3. Is it possible to have non-format-matching commits in a MR and only enforce that they are squashed into a single format-matching commit upon merging the MR?

• Do we need to validate commit messages to fit the format?

Yes.

• What happens if a commit message doesn't fit the format?

It won't be able to be included in the automatically generated CHANGELOG, nor will it be able to influence the semantic version bumps. It essentially doesn't exist in terms of the conventional commits world. We're guarding against that with commit message validations and see how it goes.

• Is it possible to have non-format-matching commits in a MR and only enforce that they are squashed into a single format-matching commit upon merging the MR?

It's possible to validate commits in CI, and have it fail until the commits match the validation. I'll look into setting that up.

It is possible to skip the validator by beginning your commit message with fixup! or squash!, per git semantics, https://github.com/marionebl/commitlint/issues/60#issuecomment-345442229:

husky > npm run -s commitmsg (node v10.0.0)

⧗   input: fixup! test
✔   found 0 problems, 0 warnings

Everything else is linted.

mentioned in commit fffde8d8

mentioned in commit 287400f3

mentioned in commit 3e2f4689

mentioned in commit 8d82c7e7

mentioned in commit c5a51d30

mentioned in commit baab3c11

mentioned in commit e1067fc5

mentioned in merge request !71 (merged)

closed via commit fffde8d8

closed via commit cbab051d

closed via merge request !71 (merged)

mentioned in commit cbab051d

mentioned in commit 009ac794

mentioned in commit 9c8ce4cb