-
Notifications
You must be signed in to change notification settings - Fork 36
Pushing out a new dev channel release
We differentiate between full pushes and cherry picks releases. Doing either of these will make the bots build the new sdk, but not release it. For releasing a specific build see the Promoting section below
Find a suitable green build on master, by looking at the bots, we call this
#MASTER_HASH_TO_BASE_RELEASE_OFF (e.g., 0162247d4130399b95ecd1ecc1a3a5d2593dc6d5).
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
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
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
The promote script will publish docs automatically to here (by pushing new files through git into the gh-pages branch):