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 1 month before release to allow time for architecture testing and bug fixes.

1. Current branches

Currently, these release branches are maintained:

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.

Distribution

Branch

EOL

ALT p9

2.27

2023-12

ALT p10

2.32

Ongoing

Debian 8 (Jessie)

2.19

2020-06-30

Debian 9 (Stretch)

2.24

2022-06-30

Debian 10 (Buster)

2.28

Ongoing

Debian 11 (Bullseye)

2.31

Ongoing

Fedora 21

2.20

2015-06-23

Fedora 22

2.21

2015-12-01

Fedora 23

2.22

2016-07-19

Fedora 24

2.23

2016-12-20

Fedora 25

2.24

2017-12-12

Fedora 26

2.25

2017-12-12

Fedora 27

2.26

2018-05-29

Fedora 28

2.27

2018-11-30

Fedora 29

2.28

2019-05-28

Fedora 30

2.29

2019-11-30

Fedora 31

2.30

2020-11-24

Fedora 32

2.31

2021-05-25

Fedora 33

2.32

2021-11-30

Fedora 34

2.33

2022-06-07

Fedora 35

2.34

2022-12-13

Fedora 36

2.35

2023-05-06

Fedora 37

2.36

2023-12-05

Fedora 38

2.37

Ongoing

Fedora 39

2.38

Ongoing

Fedora 40

2.39

In progress

IBM Advance Toolchain 12.0

2.28

2021-09

IBM Advance Toolchain 13.0

2.30

Ongoing

IBM Advance Toolchain 14.0

2.32

Ongoing

IBM Advance Toolchain 15.0

2.34

Ongoing

Red Hat Enterprise Linux 5

2.5

2020-11-30 (End of Extended Life-cycle Support)

Red Hat Enterprise Linux 6

2.12

2024-06-30 (End of Extended Life-cycle Support)

Red Hat Enterprise Linux 7

2.17

Ongoing

Red Hat Enterprise Linux 8

2.28

Ongoing

Red Hat Enterprise Linux 9

2.34

Ongoing

Ubuntu 16.04 LTS (Xenial Xerus)

2.23

2024-04

Ubuntu 18.04 LTS (Bionic Beaver)

2.27

2028-04

Ubuntu 20.04 LTS (Focal Fossa)

2.31

2030-04

Ubuntu 22.04 LTS (Jammy Jellyfish)

2.35

2032-04

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 [REQUIRED]

Each release manager should have or gradually obtain:

5. Step-by-Step Release

Process

Full Release

When?

Development

New development

6 months before release

Freeze

(./)

1 month before release

Translations

(./)

Right after freeze

Testing

(./)

All through the freeze

RM Testing

(./)

All through the freeze

News/Contrib

(./)

Just before release

Regenerate

(./)

Just before release

Final translations

(./)

Just before release

Tag

(./)

At release

Branch

(./)

At release

Upload release

(./)

At release

Move the ChangeLog

(./)

Post release

6. Release Steps

6.1. Development [REQUIRED] (6 months before release)

Active development is carried out on master.

6.2. Freeze [REQUIRED] (1 month before release)

A general development freeze should be declared some time before release.

During this period before the release, the release manager may ask committers to limit commits to master. Changes to avoid include:

6.3. Update libc.pot for the Translations project, string freeze [REQUIRED] (Right after freeze)

Some time before the release, 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:

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

6.4. Incorporate translations [REQUIRED] (All through the freeze)

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.

6.5. Testing / Machine testing [REQUIRED] (All through the freeze)

Architecture maintainers should update ABI baselines; see Regeneration. [REQUIRED]

All architecture maintainers should update the ulps baselines for libm tests as needed; see Regeneration. [RECOMMENDED]

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). [REQUIRED]

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

6.6. RM Testing [RECOMMENDED] (All through the freeze)

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

6.7. News [RECOMMENDED] (Just before release)

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

6.8. Insert list of fixed bugs in NEWS [REQUIRED]

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.

6.9. Insert list of fixed security advisories in NEWS [REQUIRED]

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.

6.10. Update manual/contrib.texi [RECOMMENDED]

Shortly before the release, check that the contributors for this releases are given credit in manual/contrib.texi.

6.11. Update manual/install.texi [RECOMMENDED]

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.

6.12. Regenerate [REQUIRED]

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.

6.13. Final Translations [REQUIRED] (Just before release)

Update translations one last time before tagging a release:

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

6.14. Prepare announcement [REQUIRED] (At release)

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

See also general GNU instructions on announcing releases.

6.15. First Tag [REQUIRED] (At release)

The release is tagged:

Send an email to libc-alpha@sourceware.org with a developer announcement about the tag.

6.16. Branch [REQUIRED] (At release)

Branch the release from master:

6.17. Prepare master for new development [REQUIRED] (At release)

Development starts for the next major release:

6.18. Prepare release branch [REQUIRED] (At release)

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

6.19. Second Tag [REQUIRED] (At release)

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").

6.20. Make tarballs and upload release [REQUIRED] (At release)

The release manager creates tarballs and sends announcements.

  1. Important: Reset your git repo to exactly the tagged release state!

     git checkout glibc-x.xx
  2. Create a tarball of the tagged release.
    • 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>

  3. 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.

  4. Ask the Bugzilla Admin Team to update the sourceware bugzilla to add a new keyword to track this release e.g. glibc_M.N.

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

6.21. Announce release [REQUIRED] (At release)

See also general GNU instructions on announcing releases.

6.22. Set up NEWS file in release branch for backports [REQUIRED] (After release)

On the just created release branch, start a section for bug fixes backported from master:

Version 2.NN (rolling release)

The following bugs are resolved with this release:

6.23. Party [RECOMMENDED] (After release)

:)

None: Release (last edited 2024-02-14 13:14:45 by CarlosODonell)