Skip to content

Instantly share code, notes, and snippets.

@shilman

shilman/RELEASE_v6.md

Last active December 28, 2019 17:16
Show Gist options
  • Save shilman/3c8b2660b28ab3e254deb120764c16e8 to your computer and use it in GitHub Desktop.
Save shilman/3c8b2660b28ab3e254deb120764c16e8 to your computer and use it in GitHub Desktop.
Download ZIP
Storybook release proposal v6
Raw
RELEASE_v6.md

Storybook Release Proposal v6

Sixth iteration of the Storybook release process (v1, v2, v3, v4, v5), updated to reflect learnings from the 5.0 release.

What we're doing now

  • We respect semver for all releases to the best of our ability
  • master is released on the latest tag every week (e.g. 4.0.2)
  • next is released on the next tag every week (e.g. 4.1.0-alpha.X)
  • Bugfixes and docs changes cherry-picked from next to master on every release
  • All major/minor releases get a blog post (e.g. 3.2)
  • Set minor release dates as soon as we have feature clarity and manage to those dates:
    • Date should be a Monday so if we slip we don't get pushed into the weekend
    • T - 3wk = feature freeze and branch release/X.y
    • T - 2wk = release RC and call for testing
    • T - 0 = release but don't announce
    • T + 1-3d = announce

Proposed changes

Rather than creating a release branch, we do all pre-releases from next. However after the feature freeze, we restrict merging PRs to next:

  • YES bugfixes
  • YES version upgrades that are security updates
  • YES documentation
  • NO new features / unncessary maintenance
  • NO random version upgrades

Stalling PRs for a few weeks adds a little friction to contribution during the release cycle, which is what we were trying to avoid by creating a release branch. However, it will make the release substantially simpler and will encourage us to get through each release faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment