Pushing out a new dev channel release

We differentiate between full pushes and cherry picks. Full pushes means taking

Doing a full push

Find a suitable green build on master, by looking at the bots, we call this #MASTER_HASH_TO_BASE_RELEASE_OFF. We call the version we are pushing $THE_VERSION_BEING_PUSHED, this is based on the actual values in tools/VERSION, but looks like this "0.1.0-dev.6.0".

git new-branch --upstream origin/dev dev
git merge --no-commit #MASTER_HASH_TO_BASE_RELEASE_OFF

Update tools/VERSION (for these full pushes reset PRERELEASE_PATCH to 0, increase PRERELEASE by 1, the updated version is your $THE_VERSION_BEING_PUSHED)

git commit -a

Update the commit message, it should read like:

Version $THE_VERSION_BEING_PUSHED

Merge commit '#MASTER_HASH_TO_BASE_RELEASE_OFF' into dev

Sanity check:

git diff #MASTER_HASH_TO_BASE_RELEASE_OFF

should only give differences in the tools/VERSION file.

Push the changes:

git push

Tag the new release:

git tag -a $THE_VERSION_BEING_PUSHED -m $THE_VERSION_BEING_PUSHED
git push --tags

Cherry picking to dev

We do this using two branches to get a nice looking history on the dev branch, and to not trigger builds with non working versions on the bots (the bot git poller will do git log --first-parent when figuring out commits.

$THE_VERSION_BEING_PUSHED has the same meaning as above. The #HASH_1 ... #HASH_N are the cls we want to cherry pick

git new-branch --upstream origin/dev cherry
git cherry-pick #HASH_1
.
.
.
git cherry-pick #HASH_N

Now, we have all the cherry picks on the cherry branch, create the branch we will use for pushing, merge the cherry picks in (to get a merge node similar to what we have for normal full pushes). We use --no-ff to get the merge node instead of fast forward commits.

git new-branch --upstream origin/dev dev
git merge --no-ff --no-commit cherry

Edit tools/VERSION, increase PRERELEASE_PATCH by 1

git commit -a

Commit message should read:

Version $THE_VERSION_BEING_PUSHED

Cherry-pick #HASH_1 to dev
.
.
.
Cherry-pick #HASH_N to dev

Sanity check the log, make sure all the cherry picks are there and that the Version commit has the right structure.

Push the changes:

git push

Tag the new release:

git tag -a $THE_VERSION_BEING_PUSHED -m $THE_VERSION_BEING_PUSHED
git push --tags

Promoting

Before promoting do some lightweight sanity checking with the new sdk (download links on the dev sdk bots) - preferably running a few samples on a raspberry pi.

If everything looks good, do:

tools/promote.py --version $THE_VERSION_BEING_PUSHED

This will copy the bits into the release directory, to the actual version directory and to latest (which is where our download link points.) It will also update the VERSION file in latest