Skip to content

Developer Guide: Releasing Inject

Jump to bottom
Jakobo edited this page Mar 19, 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. Includes the "v" and does not include RC v0.4.2
  • NEW_REV the release we are intending to make. Same rules as LAST_REV: v0.4.3

Directories and Cloning

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 as often as possible, so you don't have to juggle remote origins then. Sure, you could push to upstream, but that would just make your life more difficult unless you are AWESOMEST GIT PERSON

Create Release Branch

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

# 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

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

git push origin NEW_REV:NEW_REV

Tag Release Point (for built artifacts)

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.

  • NEW_REV_RC if this is an rc, add -rcX to the NEW_REV variable. Final versions do not have the rc suffix attached. Example: v0.4.2-rc1 
git tag -a NEW_REV_RC
# 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

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