Skip to content

Developer Guide: Releasing Inject

Jump to bottom
Jakob Heuser edited this page May 30, 2013 · 12 revisions

Congratulations!(?) You're on the hook for releasing Inject!

Terms and Variables

  • LAST_REV the latest release we have done so far. do not include the RC information for this For example: 0.4.2
  • NEW_REV the release we are intending to make. Same rules as LAST_REV: 0.4.3
  • RC_REV the release we are intending to make. It's the same as NEW_REV, but this one includes RC information: 0.4.3-rc1

Directories and Cloning (setup)

I recommend the following directories to keep yourself sane. You don't have to blow them away... it can help with later managing pull requests, iterating on the website, etc.

|-inject
  |-linkedin
  |-gh-pages
  |-yourname

cd <your_favorite_directory>
mkdir -p inject
git clone [email protected]:linkedin/inject.git linkedin
git clone [email protected]:linkedin/inject.git gh-pages
git clone [email protected]: YOUR_GITHUB_USERNAME /inject.git YOUR_GITHUB_USERNAME
cd gh-pages && git checkout origin/gh-pages && git checkout -b gh-pages && git branch -D master && cd ..
cd YOUR_GITHUB_USERNAME && git remote add upstream [email protected]:linkedin/inject.git && cd ..
  • You really want to blow away master in gh-pages... we have lots of artifacts that don't overlap
  • The upstream and "your" branches make it easier to separate work for LinkedIn (managing pull requests) and work for yourself as a contributor (sending pull requests). We all send pull requests (even people with commit access to the main repo), and this removes the need to push to multiple upstream locations.

Create Release Branch (first RC only)

These steps are needed for the FIRST RC in a series. Subsequent releases do not need this step, continue to "Update Release Branch"

# Make a new branch based on the LAST_REV and check it out
cd linkedin
git checkout origin/LAST_REV
git checkout -b NEW_REV

Update Release Branch (new RCs: rc2 to rcX)

These steps are needed for all RCs and Final versions.

Get into your release branch

cd linkedin
git checkout NEW_REV

Use one of the following strategies...

# absorb everything in master (often for a first RC)
git rebase master

# if conflicts, use
git add <fixed file>
git rebase --continue
# cherry pick a fix from master (hotfix)
git cherry-pick <SHA-1 from git-log in github>
# apply a hotfix manually... patch/apply, edit, etc
# edit your files then
git add <files>
git commit -m <message>
  • Verify your changes in git log
  • Do a diffstat to get a general sense of the release's size git diff --stat -r LAST_REV -r NEW_REV

Update package.json and bower.json

The next task is to update the package.json and bower.json, setting the "version" your RC_REV value.

Don't forget to commit this change. :)

Publishing Release Branch Changes (all RCs: rc1 to rcX and final versions)

git push origin NEW_REV:NEW_REV

or, if you're just a new RC

git push origin YOUR_REV:YOUR_REV

Tag Release Point (all builds)

In addition to publishing a release branch, we tag the point in which we make changes. This makes it possible for us to make additional builds (hotfixes) on top of a single release if required. Plus, it just makes the grunt process easier since now every build for inject identifies it's nearest build and contains a SHA-1 we can map to on github... meaning we know exactly what code someone is running.

  • RC_VER if this is an rc, add -rcX to the NEW_REV variable. Final versions do not have the rc suffix attached. Example: 0.4.2-rc1 or 0.4.3 
git tag -a RC_VER
# add your commit message. Use github's issues to populate your message with
# a list of features and changes
git push origin --tags

Create a ZIP artifact (all builds)

npm install
git submodule init
git submodule update
grunt build
open ./artifacts
  1. You'll see a shiny directory with your build, based on your tag from above
  2. Archive it (we'll make a grunt task for this soon enough...)

Putting it on InjectJS.com

  1. Go to your gh-pages branch
  2. Add the ZIP file
  3. Edit the download page (and the home page for a final release)
  4. Use jekyll --server to verify it looks good
  5. git push origin gh-pages:gh-pages in your gh-pages directory to make it go live
Clone this wiki locally