Skip to content

Instantly share code, notes, and snippets.

@lfryc
Last active December 29, 2015 05:49
Show Gist options
  • Save lfryc/7625055 to your computer and use it in GitHub Desktop.
Save lfryc/7625055 to your computer and use it in GitHub Desktop.
Draft of RichWidgets release process

Prerequisites

Environment

Node

0.10.21

Notify Development Team

The person performing a release should post a message to the #richwidgets channel on irc.freenode.net.

Review Issue Tracker Status and Continuous Integration

Before starting any release steps, make sure the continuous integration builds pass and that all issues scheduled to particular version are resolved.

Issue Tracker:

Continous Integration builds:

Finish Release Notes

dist/release-notes.adoc should be updated before starting with a release.

Release Staging

  1. Make sure all respected commits are committed in master branch.

  2. Diverge a branch stage from the latest commit on master branch (this is a branch used for release testing)

  3. Change version of the project in bower.json and package.json to release version (drop -wip suffix)

  4. Build a distribution in dist/ directory and add it to the repository using git add -f dist/

  5. Push the stage branch upstream, making it available for release verification

Release testing

At this point the release is prepared for testing by QE team.

What needs to be verified:

  • all tests pass on all supported browsers

Creating and Pushing Tag

Once the release pass QE criteria:

  1. Create a tag from latest commit on a stage branch, call the tag by a release version: e.g. 0.2

  2. Push the tag to upstream repository

  3. Remove dist/ branch

  4. Change version of the project in bower.json and package.json to development version (drop -wip suffix)

  5. Merge stage branch (that includes the tag) to master branch (so that it appears in master branch history)

  6. Drop a stage branch

Releasing

  1. Create a Release in GitHub interface

  2. Attach a built ZIP distribution (snapshot of tag sources that include built dist/)

Release verification

  • the ZIP can be downloaded from GitHub Releases view

  • the tag can be downloaded via Bower

@lfryc
Copy link
Author

lfryc commented Nov 24, 2013

Drawbacks:

  • we push a branch before it is verified - it might be better to create a temporaty tag/branch for QE purposes - e.g. 0.1.cr1

@bleathem
Copy link

Let's add some links for the CI build status and the issue tracker.

Also, the version strings in bower.json and package.json need to:

  1. drop the wip suffix prior for the commit which will be tagged (if multiple commits have this version number in the json files that's fine)
  2. increment the version number on the master branch post release, adding back the wip suffix.

@lfryc
Copy link
Author

lfryc commented Nov 27, 2013

Brian, I have worked in you suggestions.

@bleathem
Copy link

  • +1 for creating a release branch. IMO we could recycle a generic name like stage for each release, and merg/remov the branch after each release. There is no need for a release specific name in the branch. This would make CI tools and release processes easier to use.
  • The project version is in both the bower.json and package.json files. These either both need to be updated, or we should remove the version string from the one that is not being updated.

@lfryc
Copy link
Author

lfryc commented Nov 28, 2013

Okay, I have updated the process so that it works with stage branch concept:

most significantly, the release has two phases:

  1. Release staging
  2. Release tagging

We work with stage branch separately from dist branch and we merge it back to master, in order release tag to appear in master branch history.

@lfryc
Copy link
Author

lfryc commented Nov 28, 2013

Brian, can I merge it to RichWidgets at this point?

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