From: Karel Zak Date: Mon, 29 Jun 2026 11:56:25 +0000 (+0200) Subject: docs: integrate release-schedule.txt into HOWTO-CONTRIBUTING.md X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7d90e56dd5de3dc9fca2f86ecb01ee4c7ffe665b;p=thirdparty%2Futil-linux.git 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 --- diff --git a/Documentation/HOWTO-CONTRIBUTING.md b/Documentation/HOWTO-CONTRIBUTING.md index 1d2d6c549..93c2e2be8 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 cca3bca57..000000000 --- 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