/
README-release
145 lines (97 loc) · 4.99 KB
/
README-release
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
Here are most of the steps we (maintainers) follow when making a release.
* start from a clean, up-to-date git directory.
git checkout master; git pull
* Run ./configure && make maintainer-clean
* Ensure that the desired versions of autoconf, automake, bison, etc.
are in your PATH. See the buildreq list in bootstrap.conf for
the complete list.
* Ensure that you're on "master" with no uncommitted diffs.
This should produce no output: git checkout master; git diff
* Ensure that you've pushed all changes that belong in the release
and that the NixOS/Hydra autobuilder is reporting all is well:
https://hydra.nixos.org/jobset/gnu/coreutils-master
* Run bootstrap one last time. This downloads any new translations:
./bootstrap
FIXME: enable excluded programs like arch? to get their manual pages?
* Check for new file system types by running the following command on
a system with the most recent kernel possible (e.g., Fedora rawhide):
make src/fs-magic-compare
Or download the latest header first like:
kgit='https://git.kernel.org/cgit/linux/kernel/git'
wget -q $kgit/torvalds/linux.git/plain/include/uapi/linux/magic.h \
-O src/fs-latest-magic.h
If it finds a new file system magic number, add it to src/stat.c.
If it is a remote file system tag it as such.
Note there may be some new file systems magic values not defined
in that linux/magic.h file, which can be seen at:
https://www.livegrep.com/search/linux\
?q=%23define+.*_SUPER_MAGIC+-file%3Amagic\.h
* Pre-release testing:
Run the following on at least one SELinux-enabled (enforcing) and
one non-SELinux system:
n=$(( ($(nproc) + 1) / 2 ))
sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER \
make -k -j$(nproc) check-root SUBDIRS=. \
&& make distcheck \
&& make -j$n check RUN_VERY_EXPENSIVE_TESTS=yes RUN_EXPENSIVE_TESTS=yes
If testing on systems with a non standard default shell, spurious failures
may occur. Often there are other shells available, and you can select
those by using for example, SHELL=bash in the commands above.
Note that the use of -j$n tells make to use approximately half of the
available processing units. If you use -jN, for larger N, some of the
expensive tests are likely to interfere with concurrent performance-measuring
or timing-sensitive tests, resulting in spurious failures.
If "make distcheck" doesn't run "make syntax-check" for you, then run
it manually:
make syntax-check
* To set the date, version number, and release type [stable/alpha/beta] on
line 3 of NEWS, commit that, and tag the release; run:
build-aux/do-release-commit-and-tag X.Y stable
* Run the following to create release tarballs. Your choice selects the
corresponding upload-to destination in the emitted gnupload command.
The different destinations are specified in cfg.mk. See the definitions
of gnu_ftp_host-{alpha,beta,stable}.
# "TYPE" must be stable, beta or alpha
make TYPE
* Test the tarball. copy it to a few odd-ball systems and ensure that
it builds and passes all tests.
* While that's happening, write the release announcement that you will
soon post. Start with the template, $HOME/announce-coreutils-X.Y
that was just created by that "make" command.
For generating counts use:
oldrel=$(cat .prev-version)
printf "There have been %d commits by %d people %s\n" \
$(($(git log --oneline v$oldrel.. | wc -l) - 3)) \
$(git shortlog v$oldrel.. | grep "^[^ ]" | wc -l) \
"in the [X] weeks since $oldrel"
git shortlog v$oldrel.. | sed -n 's/:$//p' |
sed 's/^/ /' | column -c 70 | expand
Once all the builds and tests have passed,
* Run the gnupload command that was suggested by your "make stable" run above.
* Wait a few minutes (maybe up to 30?) and then use the release URLs to
download all tarball/signature pairs and use gpg --verify to ensure
that they're all valid.
* Push the NEWS-updating changes and the new tag:
v=$(cat .prev-version)
git push origin master tag v$v
* Announce it on Savannah first, so you can include the preferable
savannah.org announcement link in the email message.
From here:
https://savannah.gnu.org/projects/coreutils/
click on the "submit news", then write something like the following:
(If there is no such button, then enable "News" for the project via
the Main -> "Select Features" menu item, or via this link:
https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=coreutils)
Subject: coreutils-X.Y released [stable]
+verbatim+
...paste the announcement here...
-verbatim-
Then go here to approve it:
https://savannah.gnu.org/news/approve.php?group=coreutils
* Send the announcement email message (signed with the release key)
* Approve the announcement here:
https://lists.gnu.org/mailman/admindb/coreutils-announce
* After each non-alpha release, update the on-line manual accessible via
https://www.gnu.org/software/coreutils/manual/
by running this:
build-aux/gnu-web-doc-update --mirror