diff options
| author | Benno Schulenberg | 2013-10-05 18:08:59 +0200 |
|---|---|---|
| committer | Karel Zak | 2013-10-08 15:38:39 +0200 |
| commit | 55fb046138ab563c2e03403c270960c06daa921b (patch) | |
| tree | 278351bc2c90d9923167644b8b1918b2aba6019f | |
| parent | COPYING: fix grammar of referring phrase, and indicate location better (diff) | |
| download | kernel-qcow2-util-linux-55fb046138ab563c2e03403c270960c06daa921b.tar.gz kernel-qcow2-util-linux-55fb046138ab563c2e03403c270960c06daa921b.tar.xz kernel-qcow2-util-linux-55fb046138ab563c2e03403c270960c06daa921b.zip | |
docs: improve grammar and wording of the release-schedule text
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
| -rw-r--r-- | Documentation/release-schedule.txt | 45 |
1 files changed, 23 insertions, 22 deletions
diff --git a/Documentation/release-schedule.txt b/Documentation/release-schedule.txt index 6077735b1..8f5b3ad57 100644 --- a/Documentation/release-schedule.txt +++ b/Documentation/release-schedule.txt @@ -1,37 +1,38 @@ Release schedule ---------------- -The util-linux uses <major>.<minor>.<maint> version numbering. -Since the major version is pretty much fixed the release means an -upgrade of minor number. Minor version is update roughly twice -per year. Easiest way to estimate when next version will occur is -to see time stamp of previous release. - -Before a release there are few release candidates, which will be -collectively tested. During test period changes to code base are -restricted. Usually there are two release candidates. - - what length what will be accepted to upstream - ------------------------------------------------------- +The util-linux package uses the <major>.<minor>.<maintenaince> 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 next release candidate can be considered as -merge window. +The period between a release and the next release candidate can be considered +as the merge window. Release criteria ---------------- -For all releases is required: +For all releases it is required that: - - make checkincludes pass - - make checkconfig pass - - make distcheck pass - - cd tests && ./run.sh pass - - out-of-tree build works - cd .. && mkdir build && cd build && ../util-linux/configure && make + - 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: build with uClibc, --with-slang + - ideally: a build with uClibc works, and --with-slang works See also -------- |