From 7d90e56dd5de3dc9fca2f86ecb01ee4c7ffe665b Mon Sep 17 00:00:00 2001 From: Karel Zak Date: Mon, 29 Jun 2026 13:56:25 +0200 Subject: [PATCH] docs: integrate release-schedule.txt into HOWTO-CONTRIBUTING.md Move the release schedule and RC cadence information into the HOWTO-CONTRIBUTING.md file. Drop the "Release criteria" section as tests should always pass regardless of release status. Signed-off-by: Karel Zak --- Documentation/HOWTO-CONTRIBUTING.md | 12 +++++++++ Documentation/release-schedule.txt | 42 ----------------------------- 2 files changed, 12 insertions(+), 42 deletions(-) delete mode 100644 Documentation/release-schedule.txt diff --git a/Documentation/HOWTO-CONTRIBUTING.md b/Documentation/HOWTO-CONTRIBUTING.md index 1d2d6c5499..93c2e2be85 100644 --- a/Documentation/HOWTO-CONTRIBUTING.md +++ b/Documentation/HOWTO-CONTRIBUTING.md @@ -19,6 +19,18 @@ Branches: Since version 2.40, stabilization is done exclusively in `stable/` branches. +## Release Schedule + +The versioning scheme is `..`. The minor version +is incremented roughly twice per year. + +Before each release there are typically two release candidates: + +- `rc1` (1-2 weeks) — bug fixes only +- `rc2` (1-2 weeks) — translations, fatal/trivial bug fixes + +The period between a release and the next rc1 is the merge window. + ## Sending Patches - Send patches via GitHub pull request (recommended) or to the mailing diff --git a/Documentation/release-schedule.txt b/Documentation/release-schedule.txt deleted file mode 100644 index cca3bca57d..0000000000 --- a/Documentation/release-schedule.txt +++ /dev/null @@ -1,42 +0,0 @@ -Release schedule ----------------- - -The util-linux package uses the .. version -numbering scheme. Since the major version is pretty much fixed, any -release means an increment of the minor number. The minor version is -incremented roughly twice per year. The easiest way to estimate when -the next version will appear, is to look at the time stamp of the last -release. - -Before each release there are a few release candidates, which will be -collectively tested. During the test period changes to the code base -are restricted. Usually there are two release candidates. - - what length what will be accepted into upstream - --------------------------------------------------------- - rc1 1-2 weeks bug fixes only - rc2 1-2 weeks translations, fatal/trivial bug fixes - -The period between a release and the next release candidate can be considered -as the merge window. - -The release tarball is generated by "make distcheck" command. - -Release criteria ----------------- - -For all releases it is required that: - - - make checkincludes passes - - make checkconfig passes - - make distcheck passes - - cd tests && ./run.sh passes - - an out-of-tree build works - (cd .. && mkdir build && cd build && ../util-linux/configure && make) - - - ideally: a build with uClibc works, and --with-slang works - -See also --------- - -../README -- 2.47.3