Automating of Releases

[nivida]

@lautarodragan has recommended the tool semantic-release to automate the release process of web3.js. On a first view does it actually look like something we can and should use.

Highlights of semantic-release:

• Fully automated release
• Enforce Semantic Versioning specification
• New features and fixes are immediately available to users
• Notify maintainers and users of new releases
• Use formalized commit message convention to document changes in the codebase
• Integrate with your continuous integration workflow
• Avoid potential errors associated with manual releases
• Support any package managers and languages via plugins
• Simple and reusable configuration via shareable configurations

Releases can be triggered over the commit message and specified key-words.

Philosophy behind:

• Release Early, Release Often

Expected behavior

web3.js patch, minor, or major release does get published immediately after the merge of a PR into the default branch.

Actual behavior

Releases do have to be done manually.

[lautarodragan]

Thanks for considering this!

Regarding the expected vs. actual behavior: I'm not sure what you mean. If you'd prefer it to be automatic, that's totally possible (and how we have it working). We do it for our poet-js library, for example.

If it's of any help, here's our CircleCI configuration that takes care of compiling and running semantic-release, and our .releaserc.json. We use a dummy NPM account to do automated releases, but any account can do.

A note on Squash Merging:

semantic-release determines the version from the commit messages. In branches, anyone can commit whatever messages they want. That gives them a bit of control on the versioning, which will probably lead to you asking contributors to manually squash or rename their commits. It's an extra burden on you and bigger surface for issues (if you forget to review the entire commit history of a PR and only review the code and merge it, it may bump the minor when what was correct was the patch, for example).

If you do squash merging, only you @nivida and whoever else has permissions to merge PRs control the commit messages in master, which basically allows you to control NPM publishing from the PR screen 😃

Regarding the discussion in #3228, if you wind up deciding to do breaking changes as minor bumps in 1.x and mayor bumps in 2.x or master, I believe you can do that by having different .releaserc files in each branch. I haven't personally tested such an approach and I fear it may be a bit confusing to get right at first.

If you do decide something like semantic-release is right for web3.js, you'll probably need a way to support releasing fixes in the 1.x after it's marked as stable though... but now I"m just thinking aloud.

Anyways, hope this all is of any help.

[michaelsbradleyjr]

GitHub has three merge options (see screenshot immediately below):

• Create a merge commit
• Squash and merge
• Rebase and merge

It seems semantic-release is compatible with Rebase and merge.

For the Embark Framework, we've been using Rebase and merge for awhile now, and I thought I'd offer some perspective on why my team prefers it. It's very similar to Squash and merge but something we like is that it's possible to have more than one commit land in a PR. That option is coupled with a commitment/rule on our part: every commit that lands in master should be a conventional commit (cf. our guidelines, especially Type and Scope). We've been pretty good about obeying that rule; sometimes we mess up, and should probably use the Semantic PRs status check (I just activated it for embark).

For most of our PRs, there ends up being just one conventional commit; but sometimes there are 2+ (example — not the greatest example because it was accidentally merged with Squash and merge, but I'm mainly pointing out the PR's commit structure). This results in the eventual CHANGELOGs (on next release) and the commit history itself being a bit more fine-grained. We also use lerna's --conventional-commits option to calculate version bumps from our commit history.

I will note that many of us on the Embark team have been learning the ropes of Conventional Commits, etc. as we go along; so the perspective offered above may not line up with perfectly with the ideas of semantic-release. It sounds like @lautarodragan's team has a pretty good grip on it, so please don't hesitate to educate/correct me.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment, otherwise this issue will be closed in 7 days

[lautarodragan]

Not stale?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.