Release workflow

My point of view on release process:

• We should have 3 main branches:
  • master - “production” branch. Automatically released as @latest to npm
  • next - “pre-master” branch to batch changes before getting into release. Automatically released as @next to npm
  • canary - “experimental” branch to battle test experiments. Automatically released as @canary to npm
• all npm releases under @latest tag should be represented as github-release with appropriate changelog
• PRs by default should point to next branch
• next branch accepts only ready features / fixes. no WIP or experimental
• next and canary branches allowed to be rebased
• Ideally no one package.json should contain current package version, like it was with semantic-release setup
• Once next branch is ready it should be rebased into master which triggers CI workflow:
  • run prepublish scripts
  • run tests & coverage
  • determine which packages were changed and should be released (gh-releases, tags)
  • determine which version should be used for each changed package by analyzing commit messages related to them (for example, using changed files path)
  • add appropriate tags to current commit: changed-package@new-version and push tags to repo
  • create and publish release notes for each released package by analyzing commit messages related to them
  • temporary set calculated versions into package.json of packages to be released
  • release changed packages to npm
  • publish website+demos

I realize that it is pretty complicated setup and requires a lot of work that can’t be done in one step. So we should brake it down into smaller steps. For instance, we can manually set up package versions in next branch before rebasing it into master and prepare release notes by hands as well.

Also such setup most likely have some cons and flaws which I would be glad to hear and discuss. So I invite you guys to discuss it or maybe put forward your great and valuable suggestions.

[anna-bucher]

And discipline for “feat” and “BREAKING CHANGE”: these two can only affect one package (+docs+demos) at a time. We could event have pre-commit test for this.

[Guria]

follow-up #989