We will use SSSD 1.3.0 as an example. Substitute with the appropriate version where needed.
- Commit access to the SSSD upstream source and docs repositories
- A GPG key signed by at least two other members of the SSSD team.
- Maintainer privileges on the SSSD Zanata Instance. Follow the zanata guide to set up the zanata-cli tool
- A fresh clone of the SSSD upstream repository to work from
- Ensure that all tickets that were closed in this release are marked with the appropriate resolution.
- Perform a scratch build on all supported architectures.
Ensure that you have the latest version of the upstream sources.
Update the translation files.
In the root of SSSD checkout, pull new translations from zanata with:
zanata-cli pull -s . -t .
If new translations have been added to the main translations (
po/*.po), add the new language to
po/LINGUAS. Please keep them in English alphabetical order.
If new translations have been added to the manpage translations (
src/man/po/*.po), add the new language to
src/man/po/po4a.cfg. Please keep them in English alphabetical order.
autoreconf -if && ./configure && make update-po && make distcheckfrom the root
git statusfor changes to
Commit the new
Push the changes.
For the benefit of translators, push any new strings up to Zanata whenever we make a pre-release tarball:
zanata-cli push -s .
If this is the last pre-release (e.g. final beta before bugfix-only phase) String Freeze should be announced on the sssd-devel list and the Zanata site.
Tag the release and sign it with your GPG key:
git tag -s sssd-1_3_0
Push the tag. Push the tag explicitly instead of using
--tagsso that you do not push extraneous tags by mistake:
git push origin sssd-1_3_0
When tagging a beta or release candidate, the sources should be tagged twice. Once for the pure numeric value and once for the human-friendly value. So for example, if we are tagging SSSD 1.9.0 beta 2, we should do:
git tag -s sssd-1_8_92 git tag -s sssd-1_9_0_beta2
git push --tags
Use the attached perl script to produce XHTML-formatted manpages:
perl make-xhtml.pl /path/to/xml /path/to/output
Upload these manpages to public space (for example, FedoraPeople space)
Link to these files when creating the release page entry.
scripts/release.shfrom the root directory of the source checkout. This will create two files,
Create an md5sum and a sha1sum of the tarball:
md5sum sssd-1.3.0.tar.gz sssd-1.3.0.tar.gz.md5sum sha1sum sssd-1.3.0.tar.gz sssd-1.3.0.tar.gz.sha1sum
When creating a tarball for a beta or a release candidate, the resulting tarball should be renamed appropriately. To use the 1.9.0 beta 2 example:
mv sssd-1.8.92.tar.gz sssd-1.9.0beta2.tar.gz mv sssd-1.8.92.tar.gz.asc sssd-1.9.0beta2.tar.gz.asc
Update the version in version.m4 to the next point release (e.g. 1.3.1)
- Only update the version to a final release (like 1.9.0) right before releasing the final version. Bumping the version to final sooner would prevent us from being able to release another pre-release..
Push this new version:
As an example, we will branch off
sssd-1-3and let master track the development of sssd 1.4
Create a stable branch from master:
git checkout -b sssd-1-3 git push -n origin sssd-1-3 # verify everything looks sane git push origin sssd-1-3
Switch back to the master branch
On master, update the version in version.m4 to the next point release (e.g.
Push this new version:
git push -n origin master # verify everything looks sane git push origin master
Upload the tarball to the GitHub releases
- Navigate the browser to https://github.com/SSSD/sssd/releases
- Click the Draft a new release button
- Upload both the source tarball (
.tar.gz) and the GPG signature (
Add a line at the top of the Releases with links to the tarball and the GPG signature
Create a release notes page (e.g.
Generate the detailed changelog:
git shortlog previoustag..newtag
For each release, if any changes have occurred in packaging (a new directory, a new provider plugin, etc.), the release notes page should include a section notifying potential packagers of these changes. In general, this can be determined by doing (from the root of the git checkout):
git diff previoustag..newtag -- contrib/sssd.spec.in
For each release, if any changes have occurred in documentation, such as new options, options changing default values, the release notes should include a section that summarizes there changes:
git diff previoustag..newtag -- src/man
Update the documentation with links to the latest manual pages and/or Deployment Guides
Update the security sensitive options list if any new security-sensitive options were added
When releasing a final version (such as 1.9.0) after multiple preview releases, the release notes page for that final release should contain all of the changes from the various preview release note pages. This way, potential packagers and users do not need to examine all of the prerelease notes.
- Actions to take in the Pagure repository settings
- Make sure all tickets have been closed in the milestone so that it no longer appears in the roadmap
- Create a new milestone for the next minor version (even if one isn’t planned)
- Add new ticket with the title ‘Review and update SSSD’s documentation for X.Y.Z release’.
- An example of this ticket is https://github.com/SSSD/sssd/issues/4031
- Send an email to
firstname.lastname@example.org the availability of the new version.
- Announce the release on social networks