Release branch and set version

This will allow development to continue on master without affecting the release; it also allows quick-fixes to the release branch to address last-minute problems (which must of course be merged/cherry-picked back into master later).

Do not use -rc1, -rc2 etc. in version strings. Use the version that will be the actual published version. (The artifacts that get uploaded to the dist.apache.org/dev will include “-rc1” etc. in the folder name, but the contents will be as final. Therefore, turning the rc into the final is simply a case of taking the rc file and publishing it to the release folder with the correct name.)

References:

• Post on general@incubator
• Post on general@incubator

Create the release branch and set the release version number

Create a branch with the same name as the version, based off master:

git checkout master
git pull --rebase # assumes that the Apache canonical repository is the default upstream for your master - amend if necessary
git submodule update --remote --merge --recursive
for m in $MODULES; do ( cd $m && git checkout master && git checkout -b $VERSION_NAME ); done

Now change the version numbers in this branch throughout the project using the script brooklyn-dist/release/change-version.sh and commit it:

./brooklyn-dist/release/change-version.sh BROOKLYN $OLD_MASTER_VERSION $VERSION_NAME
# Now inspect the changes and ensure there are no surprises
find . -name "*.bak" -delete
for m in $SUBMODULES; do ( cd $m && git add . && git commit -m "Change version to $VERSION_NAME" ); done
git add $SUBMODULES && git commit -m "Update submodules to $VERSION_NAME"
git add . && git commit -m "Change version to $VERSION_NAME"

If you are happy with the changes, push them:

for m in $MODULES; do ( cd $m && git push apache-git $VERSION_NAME ); done

Update the version on master

The master branch will now need updating to refer to the next planned version. (This step is not required if making a “milestone” release or similar.)

The release notes should be cleared out and the version history augmented with the new version.

Example:

for m in $MODULES; do ( cd $m && git checkout master ); done
./brooklyn-dist/release/change-version.sh BROOKLYN $OLD_MASTER_VERSION $NEW_MASTER_VERSION
# Now inspect the changes and ensure there are no surprises

Open brooklyn-docs/guide/misc/release-notes.md and brooklyn-docs/website/meta/versions.md in your favourite editor and amend. For release notes this means bumping the reference to the previous version in the “Backwards Compatibility” section and putting some placeholder text elsewhere.

Then:

find . -name "*.bak" -delete
for m in $SUBMODULES; do ( cd $m && git add . && git commit -m "Change version to $NEW_MASTER_VERSION" ); done
git add $SUBMODULES && git commit -m "Update submodules to $NEW_MASTER_VERSION"
git add . && git commit -m "Change version to $NEW_MASTER_VERSION"

If you are happy with the changes, push them:

for m in $MODULES; do ( cd $m && git push apache-git master ); done

Switch back to the release branch

Move back to the release branch:

for m in $MODULES; do ( cd $m && git checkout $VERSION_NAME ); done