Skip to content

Instantly share code, notes, and snippets.

@jeremenichelli

jeremenichelli/kitt-release-draft.md

Last active June 26, 2018 13:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jeremenichelli/cabdf1ba84b479012db0da5e069c8932 to your computer and use it in GitHub Desktop.
Save jeremenichelli/cabdf1ba84b479012db0da5e069c8932 to your computer and use it in GitHub Desktop.
Download ZIP
Draft explaining how releases work now and how could work in the future in KITT
Raw
kitt-release-draft.md

KITT Release Process Draft

This draft will explain how hypothetically the release process of a new version of kitt would work if it's implemented.

PR creation process and initial setup

When an engineer, as part of the design system team or not, makes a change in the code base a new PR gets created. Commit are done following Karma's Git Commit message standard, which is how's currently managed in the repository and in all common frontend libraries from Typeform.

This is prefixing commit messages, fix for patch releases, feat for minor releases and BREAKING CHANGE footers for major releases. Along with these we have chore, test, docs and refactor which don't trigger a new version but get attached to the next released.

The proposed changes in the step are:

  • To add a label, for example release: minor to a PR (this can be done manually or automated by a bot running on the CI or a hook), as this will help organize and group PRs for a specific release.
  • PRs will not point to master as base branch but to release.

PR approval

After a change is approved it can get merge, though as a difference from today's process, it won't trigger a new version of kitt itself. An alternative is to not merged the PR, this way the team can select what to release and group features and fixes better.

The proposed changes in the step are:

  • PRs won't be merged on approval but left with an approved tag the team can filter and merge at release time.

Release day

Right now we are releasing a new version for it merge to master, and every PR. This makes releases not valuable enough, each release is just a one item list which gets lost in time when releases become daily or even hourly on heavy bug fixing days.

For releases to have an actual meaning for developers and designers, who are our customers from the design system perspective, they need to see a better step progression they can navigate and know what features and changes they need to do in their code or workflow.

Proposal

The library should have a preprogrammed release cycle that could group feature and improvements, fixes and breaking changes. Always keeping flexibility in mind, like postponing a release or grouping features depending on circumstancies as long as releasing out of the cycle because of an immediate need.

Cycles

  • 0.0.x patch release on a biweekly or weekly basis.
  • 0.x.0 minor release on a monthly basis.
  • x.0.0 major release on a quarter basis.

This is a set of periods completely flexible to any external needs of the system, but ideally releases can group bug fixes for patches, fixes and features for minors, and fixes, features and breaking changes on majors. All of them can release docs and refactor changes.

Aftermath

After a release is completed, release git commit history should be overriden but new master story to avoid possible unsyncing.

Wrap-up

A new process for releases should favor grouping features and fixes. For that a new flow could consist of:

  • Tagging pull requests as patch, minor or major.
  • Merging pull requests to a release branch that will later be merged to master.
  • Releases should be tied (unless exceptional cases) to time cycles for better grouping, cycles TBD.
  • After releases master and release branch should be sync up again.
  • Changelog release can be editted to provide richer content for adoption and migration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment