-
Notifications
You must be signed in to change notification settings - Fork 112
Home
Documentation on how to create releases for blinkpy.
Following is copied from https://github.com/aiidateam/aiida-core/wiki
We use the gitflow branching model. In short: since the last release, new features and bug fixes will have been merged into the develop branch through pull requests.
Branch off the new release branch from the latest release tag.
git checkout tags/v0.8.1 -b release_v0.8.2
Note: Usually, this branch will already exist and you can skip this step!
If develop holds bug fixes that need to go in this patch release, we need to cherry pick the corresponding pull requests and apply them to the release branch.
A patch file describes the changes to the repository as a result of a set of commits. For each pull request, Github provides a URL to download the corresponding patch file, e.g. for pull request 624:
https://patch-diff.githubusercontent.com/raw/fronzbot/blinkpy/pull/624.patch
Piping the patch file to git am:
curl https://patch-diff.githubusercontent.com/raw/fronzbot/blinkpy/pull/624.patch | git am
applies the changes introduced by pull request 624 to our current checked out branch and automatically creates a new commit.
Do this for all the pull requests that need to go in this patch release. Make sure to start at the oldest pull requests and applying the most recent pull request last in order to minimize the chances of merge conflicts.
For major and minor releases, we assume that all the changes in the current develop branch have to be included in the release. As such, branch off the new release branch directly from develop:
git fetch origin # just making sure we are up to date
git checkout origin/dev -b release_v0.9.0
If dev contains changes that cannot be included in the release, you'll need to take a different approach. One option is to follow the approach outlined above for the patch release, i.e. cherry-picking individual pull requests.
Once you've prepared the release branch locally, push it to Github
git push origin release_v0.9.0
Then, protect it from untested merges: On Github, navigate to Settings => Branches and select your branch. Check the boxes that require any pull requests to pass the tests. From this point onwards, any further bug fixes or features for the release need to be made via a pull request to the release branch.
Go through the pull requests and updating the CHANGELOG.md file with all significant changes made.
Check pull requests merged into the release branch (filter by is:pr base:release_v0.8.2)
Check pull requests merged into develop, since the release branch of the last minor (not bugfix) release was branched off:
git show --summary `git merge-base release_v0.8.0 develop`
or, if that doesn't work: git show v0.8.0
Use date to filter pull requests: is:pr merged:>2017-10-18 base:dev
NOTE: the above filter on base: is not fully correct: it will not show PRs that merged in a branch during the PR, and for which that branch was merged later into develop.
If a pull request introduces or changes functionality, it should be documented. If documentation is missing, ask the author of the pull request to provide it.
Note: This can take time, but it's a straightforward task, where you can easily ask for help from others.
Check out the release branch in your repository and make sure you have loaded a virtual environment with python 3.6+.
Update the source code version in blinkpy/helpers/constants.py by hand. Commit and push -- your branch is now ready to be released!
Merge release branch into master Now that the release branch is ready, merge it back into master via a pull request: Make sure the release_v0.9.0 branch in your fork is up to date, go to Github and create a pull request to the master branch of the official repository named Release version v0.9.0 (Note: you can also create the PR from the release_v0.9.0 branch of the official repository, if you have access to it).
After the pull request has been approved and merged, pull the changes into your local master branch, tag the final merge commit and push it to the remote:
git pull origin master
git tag -a v0.9.0 -m 'v0.9.0'
git push --tags origin master
If you accidentally tagged the wrong commit, you can delete the local and remote tags using the following commands.
git tag -d v0.9.0
git push --delete origin v0.9.0
We now need to merge master back into dev, however, do not do this directly through a pull request from master to dev. This is because there is a branch protection on develop that prevents pull requests from branches which are not up to date (this would mean that you would first have to merge dev into master). Instead, create a new temporary branch from master, into which you merge dev and then create a pull request from this new branch back into dev. In the following example we assume that the remote pointing to the main repository is labeled origin, otherwise replace it with the appropriate label.
git checkout master
git checkout -b merge_v0.9.0_into_dev
git pull origin dev
git push origin merge_v0.9.0_into_dev
After this, create a pull request from the newly created branch into dev. When the pull request is merged delete the release and the merging branch. Note that you may have to remove the branch protection from the release branch first on Github.
blinkpy/helpers/constants.py should be updated with dev version number now.
Periodically add tags to dev branch:
git pull origin dev
git tag -a v0.9.0.dev0 -m 'v0.9.0.dev0'
git push --tags origin dev
git pull origin master
python setup.py bdist_wheel
twine upload dist/*Verify that the release build was successfully uploaded by installing it in a fresh virtual environment.