Making a release
Ideally these instructions are in line with the GNOME releasing process.
We make two types of releases:
- regular releases, when we have new features or improvements, and
- "smaller" bug-fix releases, when a regular release needs patching.
The regular releases have the version number YYYY.MM, and the bug-fix releases have the version number YYYY.MM.Z, where Z is hopefully a relatively small number (1, 2, 3...).
Most of the steps below should be done in the development environment:
$ source bin/pitivi-env (ptv-flatpak) $ _
Freeze the strings
- Send an email to gnome-i18n @gnome.org to inform the translators the strings have been frozen and that in one week the release will be cut.
- It would be good to start preparing a blogpost already.
- Make sure there are no significant issues open against the current milestone.
- Move the remaining open issues somewhere else, for example to the next milestone.
- Close the current milestone.
Check your local dev env:
Make sure your sandbox is using the latest GStreamer release:
$ ptvenv --update
Check there are no uncommitted changes:
$ git status
Update the following files:
- meson.build: If doing a bugfix release, make sure the micro (Z) from the version number has been increased. If doing a regular release, update the version number with the current year and month and remove the micro, if any. Normally this is the same as the name of the GitLab milestone you just archived.
Compose the exec summary of changes, at the top. This ends up in the
.newsfile at download.gnome.org/sources/pitivi.
appstream-util news-to-appdata NEWSand copy the generated content into the appdata template.
- AUTHORS: If there are new maintainers.
Commit the changes:
$ git commit -a -m "Release <version-number>"
Create the distribution archive:
$ ninja -C mesonbuild/ dist $ ls -l mesonbuild/meson-dist/*.tar.*
On an X system,
ninja distmight not work because the unit tests fail because of X. In this case, stop X with
sudo systemctl stop gdmand use a fake X server:
xvfb-run /.../pitivi/build/flatpak/pitivi-flatpak ninja -C mesonbuild/ dist.
Install it on a real system and give it a spin. For example on Archlinux:
$ cd /tmp $ asp update pitivi $ asp checkout pitivi $ cd /tmp/pitivi/repos/community-x86_64/ $ cp .../pitivi-YYYY.MM.Z.tar.xz . $ vim PKGBUILD ... Update "pkgver" ... Make sure the filename at the end of "source" matches the copied file ... Update "sha256sums" $ makepkg $ makepkg -i $ pitivi
Create a tag and push it to the official repository. The TAG must always include the micro. This means when doing a regular release with version number YYYY.MM, the TAG is YYYY.MM.0. When doing a bug-fix release, the version number already includes a micro, so it's all fine.
$ git push origin master $ git tag -a <TAG> -m "Release <version-number>" $ git push origin <TAG>
We use tag YYYY.MM.0 instead of YYYY.MM because we want to have the option of later creating the YYYY.MM branch to the official repository, since it's not possible to have both a tag and a branch with the same name. This branch would gather backported fixes and be used for doing future YYYY.MM.Z bug-fix releases.
Publish the archive on Gnome:
$ scp mesonbuild/meson-dist/pitivi-YYYY.MM.tar.xz GNOME-USER@master.gnome.org: $ ssh GNOME-USER@master.gnome.org -t ftpadmin install pitivi-YYYY.MM.tar.xz
The tarball will appear on https://download.gnome.org/sources/pitivi/YYYY.MM/pitivi-YYYY.MM.tar.xz
Spread the word about the release
- Send an email to firstname.lastname@example.org
- Send an email to email@example.com thanking translators.
- Archlinux, click "Flag Package Out-of-Date".
- Debian, click the "unstable" Debian version and look for "maintainer".
- Fedora, look for "You can contact the maintainers of this package via email at".
Bump the Z in the version number in meson.build, for example if it was a regular release:
2020.09.1or if it was a bug-fix release:
2020.09.2. Push to the official repo:
$ git commit -a -m "Back to development" $ git push origin master
The results of the search are