What to do for a release
'Developer notes for What to do for a release '
Note that the main use of this page will be for making a normal "minor" release. If you are making a "major" release (e.g. x.y.0) then you will need to update this page first, to change the numbers. But if you are only making an "alpha" or "beta" release, some steps may be skipped, or altered slightly.
Note also that Post release there are additional things which need to be done, which are related to making a new release, for instance making a new release-section here on the wiki, or making a new release-section on the bug tracker, or making new Debian and Mac and Windows packages, so they will need to be coordinated with the appropriate people.
- 1 Prepare your repository
- 2 Translation update
- 3 Release name
- 4 Changelog and NEWS file
- 5 Working on VERSION
- 6 Create a tag
- 7 Push to repository
- 8 Announcing the new release
- 9 Post-release
- 10 See also
- 11 External links
Prepare your repository
- Check out the current stable branch:
git checkout maintenance/gramps51
- That branch name assumes that you're using the same name as the Github repository; if you're not (perhaps you don't use
maintenancein the name) use your local name.
- Make sure that your local copy is clean:
- If you have any uncommitted changes, either commit them now or stash them until after you've completed the release.
- Clean up any untracked files and make sure that the local repo is up to date:
git clean -fdx git pull --rebase
- If you had commits that hadn't been pushed yet they'll show up as "applying" messages in the output of this command. If that's the case re-run the tests and push as usual.
- Build and test to make sure that everything works, then clean the repo of all build products.
Check the About box year
Check if the year in the About box needs to be updated eg: © 2007-2017 The Gramps Developers to © 2007-2018 The Gramps Developers. Found in
- Check for new files since the last release:
cd po intltool-update -m
- That will create a file called
podirectory if there are new files that need to be scanned for translatable strings. Examine each of the files listed in
missing, adding each to
POTFILES.inif it contains translatable string constants and to
POTFILES.skipif it does not.
- Generate a new template file:
python3 update_po.py -p # makes a new gramps.pot template file git diff gramps.pot
- Examine the changes. If they're all just comments about where a string is found you need not commit the change (so the next line will restore the official file, instead of the one you just made):
git checkout gramps.pot
- If there have been changes on
msgidentries, you'll need to commit
gramps.potand ask translators to update their .po files before you can make a release:
git add gramps.pot git commit -m "Update translation template for new release"
- Check current translation files (there must be no 'fatal' errors):
python3 update_po.py -k all
- if all is well, return to the root directory:
Refer to (and update) the list of previous releases. Previously you needed to select an appropriate name but we have not named releases for several years now. You will still need to add the release though, including things like its relevant color.
Changelog and NEWS file
Section 2a of the General Public License says that if you distribute a modified version of a program: you must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
Note that the
5.1.4 below means the previous version, not the one you're about to release (which is the
git log v5.1.4.. --pretty --numstat --summary --no-merges | git2cl > ChangeLog git log v5.1.4.. --pretty --numstat --summary --no-merges -- po/*.po | git2cl > po/ChangeLog git add ChangeLog git add po/ChangeLog
- Edit and update the
NEWSfile using the new ChangeLog entries as a guide. If this is the first branch in a new series there will be no NEWS file, so look at a previous release and mimic the format.
Commit the NEWS file:
git add NEWS git commit -m "Update Changelog and NEWS files"
Working on VERSION
- Check that the
gramps/version.pyreflects the release you're about to make. It should if the version was bumped after the last release. If not, fix it.
gramps/gen/const.pyto indicate an official release:
- VERSION += git_revision + #VERSION += git_revision
- Save the changes:
git commit -am "Release Gramps 5.1.4"
- Check that the version number is correct:
python3 Gramps.py -v
- If everything looks good, push the changes:
git push origin maintenance/gramps51
- If that fails then someone pushed a commit while you were working. Return to Prepare your repository and start over.
Create a tag
Create the release tag; note the v leading the actual tag.:
git tag -am "Tag 5.1.4" v5.1.4
Push to repository
Push the changes to the repository:
git push origin v5.1.4
Move to the new release number on branch
Bump the version number in
Update the version for the release:
VERSION_TUPLE = (4, 2, ...)
Revert change on
gramps/gen/const.py so that the git revision is appended to the reported version in non-release builds:
- #VERSION += get_git_revision + VERSION += get_git_revision
git commit -am "Bump to <new version number>" git push
- Github generates a tarball automatically when we push a tag.
- Go to Github and log in if necessary.
- Select NN Releases from the line of items just above the thick line (NN is the number of releases so far).
- Find the tag you just pushed and click it, or click the "Draft a new release" button.
- Copy the NEWS file contents into the Write tab. You can use the Preview tab to check your formatting.
- Click Publish Release at the bottom of the edit area when you're satisfied with the contents.
- Go to the SourceForge files page and log in if necessary.
- Click on Stable or Unstable depending on the class of the release you're making.
- Click Add Folder and name the directory for the release version. Click "'Create'". Click your new folder to enter it.
- You can either download the Github-generated tarball or create one locallly:
python3 setup.py sdist
- Click Add File and drag the tarball to the drop area on the web page.
- Copy the release notes from GitHub into a file called README.md and upload it.
Announcing the new release
- update mantisdb(Bug/issue database) and enable the new version via Admin:Projects item for reporting issues. (You will need a high-enough status on the bug tracker in order to do this, so you can ask an appropriate person if you aren't.)
- announce on [email protected], [email protected] and [email protected] (You will need to be a member of all three lists first, to send to them.)
- announce on Gramps blog (File under: Gramps Releases and News) (not needed for an alpha or beta release)
- update News section on this wiki (not needed for an alpha or beta release)
- update the list of previous releases
- update reference to the new version on the wiki template (not needed for an alpha or beta release)
- update HeadlineNews (not needed for an alpha or beta release)
- update release date on the Download page (not needed for an alpha or beta release)
- change the topic on the IRC channel #gramps (not needed for an alpha or beta release)
/TOPIC #gramps Welcome to Gramps! The latest versions are 5.1.4 and the legacy 3.4.9 || http://www.gramps-project.org/ || Please state OS and Gramps version when asking a question. Understand that replies can take up to 2 days depending on whose watching the channel. Please consider asking on the gramps-users mailing list.
- update the version number at Wikipedia (not needed for an alpha or beta release)
- merge forward the
- Brief introduction to Git
- Running a development version of Gramps
- GrampsAIO-4 package updating - Updating the MS-Windows package
- Category:AppData - Screenshots used by Appdata - Debian