Skip to content

Latest commit

 

History

History
55 lines (46 loc) · 2.98 KB

RELEASES.md

File metadata and controls

55 lines (46 loc) · 2.98 KB
Raw

What is our release process?

We are currently doing time-based releases. This is a release process inspired by many other projects: GitLab release process, GNOME's Time-Based Release Schedule, Ubuntu's TimeBasedReleases.

Choosing time-based releases gives us a few benefits:

  • We can keep a regular pace of development
  • Motivation for finishing something at a given time increases
  • People working on the software can have some expectations of what they're working on
  • People using the software can have confidence about when releases come out

The most important part is to release when we say we will, even if that means cutting items from the release. In this process, it's better to be consistent with release dates than it is to hold out for a specific feature.

When do we release?

We release a new version every Tuesday at 9AM Pacific. The date and time were chosen arbitrarily and will probably change in the future as development slows down.

The Monday before release we freeze the code at 9AM Pacific. This is to prevent a last-minute dash to get something in without checking it over. The rest of the time between freeze and release is dedicated to making release notes, testing the version and preparing distributions.

How do we release a new version?

  1. Freeze the code at 9AM Pacific the Monday prior.
  2. Find all of the issues between the previous release and the current release.
  3. Add an entry to the CHANGELOG.md that has the new version and all changes.
    • Separate the changes into additions, [breaking] changes, and deletions.
    • Even if the change is a "bug fix" it fits into one of these categories.
  4. Update the version in internal/version.bzl with the version being released.
  5. Merge all changes into master.
  6. Create a tag with the version being released.
    • Do not prefix the version with a v. The prefix is arbitrary and unnecessary. So, we're arbitrarily deciding to not have it. For example: if we're on version 2.3.1, make the tag 2.3.1.
    • This will kick off builds of the Linux, OSX, and Windows binaries and publish them to our Bintray package.
  7. Copy the entry from the CHANGELOG.md to the release notes on the Bintray package.
  8. Download a binary on your machine and test a few files.
  9. Publish the package on npm.
  10. Celebrate! 🎉
    • Releasing software is a great thing, and no small effort. Be proud of your accomplishment.