-
Notifications
You must be signed in to change notification settings - Fork 86
Release & Build Procedures
Make sure to merge everything from the oldest actively developed branch up through the devel branch you're going to cut a release from. This currently means merging 3.1-devel to 3.2-devel and so on up to master.
$ git fetch
$ git checkout 3.1-devel
$ git reset --hard origin/3.1-devel
$ git checkout 3.2-devel
$ git reset --hard origin/3.2-devel
$ git checkout master
$ git reset --hard origin/master
$ ./scripts/git-multi-merge origin 3.1-devel 3.2-devel masterNOTE: It's best to merge from the remote tracking branch to avoid merging the wrong version of the branch, eg: git merge --no-ff origin/3.0-devel. We don't do that in the above example after the first merge because having done the hard reset in the previous step assures that each local branch matches its remote tracking branch.
NOTE: Make sure to do non-fast-forward merges so they are explicit by passing the --no-ff option to git-merge (as in the examples above).
Once all of the branches have been merged up, update the release branch you plan to make a new release on and merge the devel branch into it:
$ git checkout 3.2-release
$ git reset --hard origin/3.2-release
$ git merge --no-ff origin/3.2-develScan through the changes in the new release and add any that seem relevant to release_notes.rst using that file's existing structure from previous releases. You will commit the release notes changes along with the other release artifacts in the next step.
To bump the version, update it in all of the necessary places, and generate the changelog for the rpm spec file, run make bumpver. Take a look at the changes using git diff to make sure it all looks correct. Then commit the new version using git commit -a -m "New version: <version>" (eg: git commit -a -m "New version: 3.2.0").
Next, tag the new release with the command make release. This will prompt you for a GPG key passphrase in generating a signed tag, and will generate a tar archive containing the new release along with current translations. (NOTE: The upstream release on github does not contain the translations.)
Push the new release and tags to the upstream remote (git push && git push --tags).
After pushing the tags to GitHub go to the Releases page and create a new release from the pushed tag by selecting the appropriate tag (eg: blivet-3.2.2) and selecting Edit tag in the UI. Change the release title to something like blivet 3.2.2, fill in the description and attach source tarballs generated with make release.
Generate documentation for the new release
make -C doc html
Copy the documentation from doc/_build/html to a temporary directory, switch to the gh-pages, copy the documentation back and commit and push the changes.
If necessary, install the fedpkg package (dnf install fedpkg).
If necessary, create a new directory for dist-git (mkdir -p ~/src/fedora).
Change to the dist-git directory (cd ~/src/fedora).
If necessary, clone the python-blivet repo (fedpkg clone python-blivet).
Change the the python-blivet clone directory (cd python-blivet).
Make sure to pull latest changes using git pull.
If necessary, switch to the appropriate branch (fedpkg switch-branch master).
Copy the new archives and spec file to the dist-git clone:
$ cp blivet-3.2.2.tar.gz blivet-3.2.2-tests.tar.gz python-blivet.spec ~/src/fedora/python-blivet/
Upload the new release archives to the lookaside cache: fedpkg new-sources blivet-3.2.2.tar.gz blivet-3.2.2-tests.tar.gz.
Generate a changelog: fedpkg clog.
Stop and check the clog file and the output of git diff. Does everything look right? If there are changes aside from the new archive version and associated new changelog entries, you may have to sort out the confusion before you proceed.
Commit the changes: git commit -a -F clog.
Now is a good time to do a test build: fedpkg mockbuild (locally) or fedpkg scratch-build --srpm (in koji).
Assuming the mock build was successful, push the changes: fedpkg push.
fedpkg build
During certain periods of the release cycle you may also have to do an update to get the package to Fedora repositories: fedpkg update.
This is necessary for all currently released stable versions of Fedora and for development versions past the Bodhi updates-testing activation point which usually happens together with the Beta Freeze, check Fedora release schedule for exact dates.
Repeat the build for all currently supported versions of Fedora with same Blivet minor release. Eg. when doing new 3.2.2 release, do the build for all versions of Fedora with 3.2.1. You can use Fedora Packages application to check which version of blivet is in each supported Fedora release.
Prepare archive for PyPI: python3 setup.py sdist bdist_wheel
Check the archive: twine check dist/*
Upload to Test PyPI (optional): twine upload --repository-url https://test.pypi.org/legacy/ dist/*
Upload to PyPI: twine upload dist/*