FM / util-linux

/usr/share/doc/util-linux

Name	Size	Mode	Actions
examples/	-	0755	rm
releases/	-	0755	rm
00-about-docs.txt	260	0644	edit dl rm
AUTHORS.gz	15113	0644	edit dl rm
blkid.txt	3258	0644	edit dl rm
cal.txt	2262	0644	edit dl rm
changelog.Debian.gz	2654	0644	edit dl rm
col.txt	1913	0644	edit dl rm
copyright	23045	0644	edit dl rm
deprecated.txt	3086	0644	edit dl rm
getopt.txt	992	0644	edit dl rm
getopt_changelog.txt	1927	0644	edit dl rm
howto-build-sys.txt	3193	0644	edit dl rm
howto-compilation.txt	2945	0644	edit dl rm
howto-contribute.txt.gz	3437	0644	edit dl rm
howto-debug.txt	2437	0644	edit dl rm
howto-man-page.txt	126	0644	edit dl rm
howto-pull-request.txt.gz	4260	0644	edit dl rm
howto-tests.txt.gz	1706	0644	edit dl rm
howto-usage-function.txt.gz	2328	0644	edit dl rm
hwclock.txt	147	0644	edit dl rm
modems-with-agetty.txt	2614	0644	edit dl rm
mount.txt	521	0644	edit dl rm
NEWS.Debian.gz	1897	0644	edit dl rm
PAM-configuration.txt	671	0644	edit dl rm
parse-date.txt.gz	8124	0644	edit dl rm
pg.txt	448	0644	edit dl rm
poeigl.txt.gz	8867	0644	edit dl rm
README.Debian	481	0644	edit dl rm
release-schedule.txt	1354	0644	edit dl rm

Edit: /usr/share/doc/util-linux/release-schedule.txt (1354B)

Release schedule
----------------

The util-linux package uses the <major>.<minor>.<maintenance> 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

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