• Release

Release Process

Stable Glibc releases are further maintained in release branches, where they continue to receive backports of bugfixes committed to the main development branch (master). Thus, users will be able to get a glibc with many bugfixes from mainline (compared to the "main release" 2.27). Releases happen every 6 months around 1st February and 1st August, subject to any regressions or ABI issues. Exact release dates for future releases are decided by consensus and are tracked in their respective release pages. The source tree is frozen 6 weeks before release to allow time for architecture testing and bug fixes.

1. Current branches

Currently, these release branches are maintained:

• Release/2.32 by Carlos O'Donell

• Release/2.33 by Adhemerval Zanella

• Release/2.34 by Carlos O'Donell

• Release/2.35 by Carlos O'Donell

• Release/2.36 by Carlos O'Donell

• Release/2.37 by Carlos O'Donell

• Release/2.38 by Andreas K. Hüttel

• Release/2.39 by Andreas K. Hüttel

• Release/2.40 by Andreas K. Hüttel

• Release/2.41 by Andreas K. Hüttel

• Release/2.42 by Andreas K. Hüttel

• Release/2.43 by Andreas K. Hüttel

• Release/2.44 is planned for 2026-08-01 (upcoming release).

See Glibc Timeline for the release timelines.

Notes: When creating a new release page, chose the ReleaseXYTemplate page template!

2. Distribution Branch Mapping

The following is the mapping of actively supported distribution branches, public or private, with respect to the upstream glibc branches.

The following is the mapping of distribution branches beyond their EOL date with respect to the upstream glibc branches.

3. General policy

Each release branch owns a Git ref namespace release/VERSION/, recommended structure being release/VERSION/master for development, while tags are made under the common scheme glibc-VERSION.REVISION (i.e. glibc-2.27).

Normally, a release branch is forked off master after the stable version is tagged (usually, commits intended to update the version appear for few days after the version is tagged and the release branch would diverge only right before version.h is updated to reflect start of development for next main version), and consists purely or almost purely of cherry-picked fixes committed to the master branch.

Each branch is maintained by a single release manager, who has the responsibility of maintaining the particular stable branch, has final say on what goes in. The branch is expected to receive many liberally merged bugfixes from master at the beginning when many new bugs are found, then become more conservative and decrease the rate of back-ports as most major problems are solved and the branch is being propagated to more mature distribution versions. Usually, the interested committers have discretion over which bugfixes to pick for back-porting, but if discussion arises, general consensus of the community is sought, the default choice being to err on the conservative side. Patch backports to stable branches are discussed on the libc-stable mailing list, and any patch on master that doesn't change ABI or API is immediately suitable for backporting to a stable branch. It is polite to post your backport to libc-stable (in parallel with your commit) and explain the reason for the backport; this helps distro maintainers decide if they want to sync to get the fix.

It is best if a release manager volunteers, and is agreed by the community, at the start of mainline development leading to the new release (for example, a 2.28 release manager should be agreed around the time 2.27 is released). If a release manager is agreed at that time, they may then agree a release timetable with the community for the next stable release and branch. If you would like to try this out, and especially if you have some interest in the branch well-being (e.g. you are distro maintainer who will base a distro branch on top of this release), feel free to just suggest yourself on libc-alpha!

Anyone can suggest a fix committed on master (unless it's N/A for master for some reason - in that case, discussion about the patch is expected) to be included in a release branch, either by marking it by an appropriate keyword in bugzilla, or cherry-picking it themselves and sending a pull request. Developers with glibc commit permissions can in general push into any release branch, but they are expected to execute reasonable judgement and follow the branch policies. All cherry-picked commits should be created using git cherry-pick -x to indicate the id of the original commit in the commit message (see details on cherry-picking in Git). Always aim at having one cherry-picked commit for one original commit.

As of today the release branches are rolling releases that accumulates fixes and are consumed directly by distributions.

Final words: Always keep in mind the GNU copyright discipline.

4. New Release Manager

Each release manager should have or gradually obtain:

• Push access to git.sourceware.org.
• A published (preferably well cross-signed) PGP key for signing release tags.

5. Release Steps

5.1. Development (6 months before release)

Active development is carried out on master.

5.1.1. Development preparations

• Create wiki page for the coming branch from ReleaseXYTemplate template, and link it here at the top of the page.

• Ensure that the target milestone for the upcoming release exists in bugzilla.

5.2. Soft Freeze (6 or 7 weeks before release)

A soft development freeze should be declared 6 weeks before release (7 weeks if the new year holidays fall into the timeframe). The soft freeze is intended for the completion and inclusion of feature sets that are already well-progressed, under review and near completion.

• No *starting* of new features anymore
• Decisions on what goes still in and what goes not
• Review and addition of patches

The list of desirables and release blockers on the release wiki page is populated, and the patch review meeting focuses on these topics.

Anything that is already well underway can be proposed for inclusion, however, it's possible that features will be deferred still if they are not finished by the time of the next freeze stage.

Changes to avoid include:

• Anything requiring ports architecture maintainers to update their ports (the period should allow them to catch up with any updates left from the previous development).
• Anything changing the public ABI and so requiring check-abi updates on each architecture, or adding libm tests that will require ulps updates on each architecture (again, the period allows for architecture maintainers to update these files and get them ready for the release).
• Anything that subjectively seems too risky.

5.3. Freeze (4 weeks before release)

• No more additions to the desirables list (except for newly discovered bugs)
• Ideally, no more string changes
• Machine testing

5.3.1. Update libc.pot for the Translations project, string freeze

Regenerate libc.pot. See Regeneration for details.

If there are any new messages or changes to messages since the last libc.pot submitted to the Translation Project, generate a snapshot tarball. Submit it to the Translation Project so translations can be updated before the release.

The step by step process is like this:

• Regenerate libc.pot, review the changes and check it in.

• Generate tarballs using make dist.

• With the help of a project steward upload snapshot to alpha.gnu.org using gnupload e.g. ./gnupload --to alpha.gnu.org:glibc glibc-2.26.9000-1108-gee61d02850.tar.bz2 (Careful that absolute path to tarball is also appended on the remote host). Do not upload to ftp.gnu.org, only official releases should be uploaded there.

• Email coordinator@translationproject.org with the URL of the snapshot tarballs, for example:

  From: You
  To: coordinator@translationproject.org
  Subject: libc-2.36.9000.pot
  
  Translation Project,
  
  The GNU C Library is about to release version 2.37.
  
  * Complete snapshot of 2.37 release containing `po/libc.pot':
  https://alpha.gnu.org/gnu/glibc/glibc-2.36.9000-????-????????.tar.bz2
  
  Cheers,
  You.

This also means that we're now technically in string freeze (the addition or modification of translateable strings is prohibited).

(How do we handle it if the patchsets added during soft freeze include string changes? Send another version to translators late in the process?)

5.3.2. Regularly incorporate translations

Monitor the libc-alpha mailing list for notifications of new translations being available. The subject is of the form "New $LANG PO file for 'libc'". The maintainer can then incorporate the translation by running the following command in the build directory:

make -r PARALLELMFLAGS="" -C <source directory>/po objdir=`pwd` update-translations

This should download all of the latest translations, merge them in and trim untranslated strings, giving a minimal change against master. Finally, send a message to the list indicating which language translations have been merged.

5.3.3. Testing / Machine testing

Architecture maintainers should update ABI baselines; see Regeneration.

Starting with the hard freeze, architecture maintainers should test glibc for their architectures using the testsuite to make sure it is working well (the release manager should ask them to do so).

Test suite results should be collected on the release wiki page, accompanied by the following information:

==== machinename ====
Build system:
 * Compiler: gcc -v
 * Binutils: as -v
 * Kernel: uname -a
 * Tester: Your Name
 * Branch master at COMMIT HASH
 * possibly notes on config options or *FLAGS

Places where to find exotic hardware include

• the GCC compile farm, https://portal.cfarm.net/machines/list/

• matoro's isa-sandbox, https://static.matoro.tk/isa-sandbox-faq.html

5.4. Hard Freeze (2 weeks before release)

• Bug fixes only.
• Release manager testing.
• If there are no blockers anymore, the release can occur.

5.4.1. RM Testing

In an attempt to increase the quality of a release we run the following additional testsuites at this time:

• GnuLib Testsuite - the results can be documented at the end of the release page

• Linux Testsuite Project (LTP) [OPTIONAL]

• Coverity open source scanning [OPTIONAL]

5.5. Release

Lots of steps. Do them in order as listed here, unless you know exactly what you are doing.

5.5.1. News

Shortly before the release, look for any significant user-visible changes not mentioned in the NEWS file and add them to that file.

5.5.2. Insert list of fixed bugs in NEWS

On bugzilla, go through the list of bugs that mention the upcoming release as target milestone but are not marked as fixed. If they are fixed, mark them as such (so they are picked up by the script below).

There should be a placeholder at the bottom of the NEWS file section for the new release:

The following bugs are resolved with this release:

  [The release manager will add the list generated by
  scripts/list-fixed-bugs.py just before the release.]

Replace that last paragraph by the (UTF-8) output of scripts/list-fixed-bugs.py (with version number as argument, e.g. scripts/list-fixed-bugs.py 2.123) and commit the result.

5.5.3. Insert list of fixed security advisories in NEWS

There should be a placeholder at the bottom of the NEWS file section for the new release:

The following CVEs were fixed in this release, details of which can be
found in the advisories directory of the release tarball:

  [The release manager will add the list generated by
  scripts/process-advisories.sh just before the release.]

Replace that last paragraph by the (UTF-8) output of scripts/process-advisories.sh news and commit the result.

5.5.4. Update manual/contrib.texi

Shortly before the release, check that the contributors for this releases are given credit in manual/contrib.texi. This means going through the commit log and weighing whether to change, update, add entries.

5.5.5. Update manual/install.texi

Shortly before the release, test building with the most recent GCC release and update the statement in manual/install.texi about the most recent GCC release with which building glibc was tested. Similarly for binutils and texinfo. Regenerate the INSTALL file.

5.5.6. Regenerate

After testing and shortly before the release (perhaps a week before) regenerate all files that need regeneration. See Regeneration.

Please note that make dist-prepare is not sufficient for this use case since it should regenerate files even if the timestamps are up to date.

Also update translations one last time before tagging a release:

make -r PARALLELMFLAGS="" -C <source directory>/po objdir=`pwd` update-translations

5.5.7. Prepare announcement

Prepare the announcement text locally. Recommended contents is as follows:

• FROM: Release Manager <you@exmaple.com>
  SUBJECT: The GNU C Library version X.Y is now available
  
  The GNU C Library
  =================
  
  The GNU C Library version X.Y is now available.
  
  The GNU C Library is used as *the* C library in the GNU system and
  in GNU/Linux systems, as well as many other systems that use Linux
  as the kernel.
  
  The GNU C Library is primarily designed to be a portable 
  and high performance C library.  It follows all relevant 
  standards including ISO C23 and POSIX.1-2024.  It is also 
  internationalized and has one of the most complete 
  internationalization interfaces known. 
  
  The GNU C Library website is at http://www.gnu.org/software/libc/
  
  Packages for the X.Y release may be downloaded from:
          http://ftpmirror.gnu.org/libc/
          http://ftp.gnu.org/gnu/libc/
  
  The mirror list is at http://www.gnu.org/order/ftp.html
  
  Distributions are encouraged to track the release/* branches
  corresponding to the releases they are using.  The release
  branches will be updated with conservative bug fixes and new
  features while retaining backwards compatibility.
  
  NEWS for version X.Y
  ====================
  
  <Cut and paste from NEWS file>
  
  Release Notes
  =============
  
  https://sourceware.org/glibc/wiki/Release/X.Y
  
  Contributors
  ============
  
  This release was made possible by the contributions of many people.
  The maintainers are grateful to everyone who has contributed
  changes or bug reports.  These include:
  
  <git shortlog --summary -w72 glibc-(Previous X.Y tag).. | sed -e 's,^.*\t,,g'>
  
  We would like to call out the following and thank them for their
  tireless patch review:
  
  <git log glibc-(Previous X.Y tag e.g. 2.36).9000..HEAD | grep -e 'Reviewed-by:\|Reviewed-By:' | sed -e 's,^.*: ,,g' -e 's, <.*$,,g' | sort -u>

See also general GNU instructions on announcing releases.

5.5.8. Release Tag

The release is tagged:

• Update RELEASE to "stable" and VERSION to "X.Y" e.g. "2.28" in version.h.

• Update __GLIBC_MINOR__ in include/features.h.

• Push the commit (which includes the version.h, include/features.h). This is required so the ChangeLog includes this change.

• Use the gnulib vcs-to-changelog utility to generate and commit a ChangeLog file since the last release, as a new file ChangeLog.old/ChangeLog.N (where N is one more than the highest numbered ChangeLog file in that directory):

   ${gnulib_dir}/build-aux/vcs-to-changelog.py -q scripts/vcstocl_quirks.py glibc-2.<rev-1> HEAD > ChangeLog.old/ChangeLog.N

• Push the ChangeLog update as a distinct commit, e.g., "Create ChangeLog.old/ChangeLog.N."

• Create a signed tag glibc-X.Y

  • Create the tag using git tag -s; verify it's signed by the PGP key you want to sign it with.

  • The tag comment shall contain the full announcement text you just prepared.

5.5.9. Make tarballs

The release manager creates tarballs and sends announcements.

• Use make dist in a build tree - it will generate couple of ../glibc*tar* files.

• Verify the tarballs are sensible, try to build the glibc from the tarball (e.g. using it as source for your distribution package).

  • configure --prefix=/usr

  • make

  • make check

  • make install DESTDIR=<PATH>

  • make localedata/install-locales DESTDIR=<PATH>

  • make localedata/install-locale-files DESTDIR=<PATH>

5.5.10. Upload the release

• With the help of a project steward sign + upload your tarballs to ftp.gnu.org - see below for a gnupload invocation that can make your life easier.

  • You may use gnupload to easily sign and upload your tarballs:

    gnupload --to ftp.gnu.org:glibc \
        glibc-2.11.1.tar.gz glibc-2.11.1.tar.bz2 glibc-2.11.1.tar.xz

  • If you don't have PGP key on gnu.org then you may ask CarlosODonell (Project Stewared), or SiddheshPoyarekar (Previous Release Manager) for assistance with the uploads.

• Check for the tarballs to appear on the download site.

5.5.11. Prepare master for new development

Development starts for the next major release:

• On the master branch, update RELEASE to "development" and VERSION e.g. "2.28.9000" in version.h

• Create a section for the next release in the NEWS file:

  Version 2.NN
  
  Major new features:
  
    [Add new features here]
  
  Deprecated and removed features, and other changes affecting compatibility:
  
    [Add deprecations, removals and changes affecting compatibility here]
  
  Changes to build and runtime requirements:
  
    [Add changes to build and runtime requirements here]
  
  Security related changes:
  
  The following CVEs were fixed in this release, details of which can be
  found in the advisories directory of the release tarball:
  
    [The release manager will add the list generated by
    scripts/process-advisories.sh just before the release.]
  
  The following bugs were resolved with this release:
  
    [The release manager will add the list generated by
    scripts/list-fixed-bugs.py just before the release.]

5.5.12. Second Tag

A second tag is required for the first commit on the master branch after the release (the one that changes version.h back to "development").

• The tag name is the version of the release with .9000 appended to it (the same pseudo-version which is in VERSION in version.h) e.g. glibc-2.28.9000 for the 2.29 development cycle.

• Create the tag using git tag -s or git tag -a.

• The tag comment should be like this (after the glibc 2.28 release):

  Open master branch for glibc 2.29 development

The tag comment should refer to the *next* release, and the version in the tag itself is chosen in such a way that it sorts between the current release and the next.

5.5.13. Create release branch

Branch the release from master:

• Create a release/X.Y/ branch from master on glibc using the tag made in the previous step:

  git branch release/X.Y/master glibc-X.Y
  git push origin release/X.Y/master

5.5.14. Prepare release branch

• git checkout release/X.Y/master
• In the release branch, remove the advisories directory and instead add a text file ADVISORIES

For the GNU C Library Security Advisories, see the git master branch:
https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;hb=HEAD

• start a section in NEWS for bug fixes backported from master:

Version 2.NN.1

The following bugs are resolved with this release:

• push the release branch to the server: git push -u origin

The branch is effectively a rolling release. If a release manager wanted to cut the .1 release they would do so using the information collected under the 2.NN.1 section. Traditionally we don't cut another release and the branch is used as the rolling release e.g. ABI stable, bug fixes, performance improvements. Please note that git describe still calls the branch 2.NN rather than 2.NN.1 since no .1 release has been made.

5.5.15. Push tags and re-open master

• Push the release tag git push origin glibc-X.Y to the remote server for everyone to reference.

• Push the second tag git push origin glibc-X.Y.9000 to the remote server for everyone to reference.

• Send e-mail to the libc-alpha mailing list that the master branch is open for development again.

5.5.16. Announce release

See also general GNU instructions on announcing releases.

• Send a mail with your announcement to libc-alpha@sourceware.org, libc-announce@sourceware.org, and info-gnu@gnu.org.

• Update the release page e.g. https://sourceware.org/glibc/wiki/Release/2.28, with status.

• Update HomePage and Glibc Timeline.

• Also announce the release in the news feed of the Savannah site for aggregation at planet.gnu.org. This involves logging into Savannah, clicking My Groups, then GNU C Library, and then News and Submit.

• Announce it on Mastodon with #glibc and @gnutools.

• Announce it on LinkedIn and LinkedIn glibc developers group. Post only a single line comment about the release and include a link to the libc-alpha annoucement (avoids moderation delays for posting a large post). If your post doesn't show up then get a project steward to approve the post since it's probably stuck in moderation.

5.5.17. Various updates

• Ask the Bugzilla Admin Team to update the sourceware bugzilla to add a new version and milestone to track the NEXT release e.g. M.N. Versions and milestones must be added when development starts for a release, not after branching (for example, create those for 2.29 at the time 2.28 branches), but if the newly branched version does not already have them, then they should be created at that time. This is important since it allows downstream users and distributions to discover and file bugs for the in-development version of glibc and get them fixed before GA.

• Ask the Web Admin Team to update the glibc homepage https://sourceware.org/glibc/ , updating the status and adding a news item that links to the release announcement on the main page (libc.html) and updating version numbers elsewhere (sources.html, and started.html).

• Also have them build and upload the the manual at https://sourceware.org/glibc/manual/ for the release.

• Get one of the project stewards to accept the Savannah news submission (same process but click Manage instead of Submit and the steward reviews the text and clicks Submit

5.6. Party (After release)