Document / Improve publication processes

[slifty]

Task

Description

We have a few issues that came up from publishing recently, and since we hope to move other repositories to have published packages, this is a meta issue.

1. We published a major version of base-interfaces with a mistake, which forced TWO major version releases in the span of 30 minutes. That' no good.

2. We recently learned that we were missing a build step in our publishing processes, which meant that version 1.1.0 of base-constants did not actually include the new features in the published package.

We are going to make mistakes, so really this is a problem with our process.

• First: I would like us to have processes around publishing release candidates / beta / alpha versions for any breaking changes.

• Second: since we're in a period of rapid development, and we accidentally skipped past the 0.*.* versioning that SemVer allocated exactly for rapid development, I would urge us to put ANY major change into a beta / pre-release with the intent that we'll "live" on the pre-release until our APIs are locked in / we get past the fluid stage.

• Third: We should document our release processes, this can / should be done in the meta repo; I'm comfortable with either a wiki or a committed RELEASE.md file. We should make an issue to capture this request.

• Fourth: We should look into improving our automation, especially in monorepos. We ditched lerna (which I think is good) but now publishing is a manual and therefore error prone process. I'm uncomfortable with it all!

Relevant Resources / Research

• this captures some pre-release gotchas on npm

Related Issues

None.

[slifty]

This issue has some more information about our current publishing steps: tvkitchen/base#11