Skip to content

Developer Guide: Releasing Inject

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

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

Terms and Variables

  • LAST_REV the latest final release we have done so far. do not include the RC information for this For example, if we are releasing 0.4.3-rc2, then LAST_REV is 0.4.2
  • NEW_REV is the new final release we are intending to make. do not include the RC information for this. For example, if we are releasing 0.4.3-rc2, then NEW_REV is 0.4.3
  • RC_REV the release we are intending to make. includes RC information. For example, if we are releasing 0.4.3-rc2, then RC_REV is 0.4.3-rc2

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
  |-bower
  |-gh-pages
  |-yourname

cd <your_favorite_directory>
mkdir -p inject
git clone git@github.com:linkedin/inject.git linkedin
git clone git@github.com:linkedin/inject-bower.git bower
git clone git@github.com:linkedin/inject.git gh-pages
git clone git@github.com: 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 git@github.com: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 and final)

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

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.

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)

rm -rf node_modules
npm install
git submodule init
git submodule update
grunt release

Inside of /.artifacts you will see your shiny code.

Update Bower Reference (final builds only for now)

Once you've got a ZIP file, you can update bower. Grab the zip file, crack it open, and put the contents into the bower/dist directory.

Then, update the bower.json to reflect the proper version, which should be NEW_REV. Commit that change.

Create a tag git tag -a NEW_REV and then push it all up

git push origin
git push origin --tags

Bower will automatically pick up these changes.

Putting the ZIP on InjectJS.com

  1. Go to your gh-pages checkout
  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