Release policy
In the GnuTLS project there are at most two ongoing releases, one marked as
'stable' and one marked as 'next'. The former is always present and
supported, while the latter is introduced on the discretion of the
development team.
For both release branches all the rules in CONTRIBUTING.md
apply, but in principle the 'stable' release is more conservative in new features,
while the 'next' branch allows for mild behavioral changes. The 'stable' branch
always provides API and ABI compatibility, while the 'next' branch may on exceptional
cases change the API.
| Branch |
Version |
Release interval |
| stable |
3.6.x |
bi-monthly |
| next |
- |
|
Release process
- Create a new 'milestone' for the next release and move all issues present in the
current release milestone.
- Verification of release notes: ensure that release notes (NEWS) exist
for this release, and include all significant changes since last release.
- Update of release date in NEWS, and bump of version number in
configure.ac as well as soname numbers in m4/hooks.m4.
- make distcheck
- git tag -s $(VERSION). The 3.6.12 was including both the 3.6.12 and
gnutls_3_6_12 tags, but it may make sense to only use the version from
now on.
- git push && git push --tags
- make dist && gpg --sign --detach gnutls-$(VERSION).tar.xz
- scp gnutls-$(VERSION).tar.xz* trithemius.gnupg.org:/home/ftp/gcrypt/v3.6/
- Create and send announcement email based on previously sent email to the list and
NEWS file.
- Create a NEWS entry at web-pages repository,
and/or a security advisory entry
if necessary. The NEWS entry is usually pointing to the announcement email.
A commit auto-generates the gnutls web site
which is mirrored twice a day by www.gnutls.org.
- Use the @GnuTLS twitter account to announce the release.
- Close the current release milestone.