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
146
147
148
149
150
151
152
153
154
155
156
157
|
.. _create-new-release:
Create new Modules release
==========================
This document is a guide to draft then publish a new release of Modules. It
provides all the information from building the distribution tarballs to
updating external resources providing Modules.
Versioning policy
-----------------
Modules project follows `Semantic Versioning 2.0.0`_. Version number has the
``MAJOR.MINOR.PATCH`` form. For a new release, increment the:
* ``MAJOR`` when you make incompatible changes
* ``MINOR`` when you add backward-compatible features
* ``PATCH`` when you add backward-compatible bug fixes
.. _Semantic Versioning 2.0.0: https://semver.org/
Release commit
--------------
At this point, all changes visible by user for this release should be
described in :file:`NEWS.rst` and :file:`doc/source/changes.rst`. Prominent
new features should be described with examples in :file:`MIGRATING.rst`.
Finalize release content:
* Update version number in :file:`version.inc.in` and
:file:`doc/source/conf.py`
* Set release date in :file:`NEWS.rst` and :file:`MIGRATING.rst`
* Update version number and draft changelog message in
:file:`share/rpm/environment-modules.spec.in`
* Changelog should mention release author and date
* Indicate that release version is updated
* Describe any other changes made to the RPM spec file since last release
* Update release date in any documentation file that demonstrates
``module --version`` output.
* If Modules Tcl extension library has been changed since last release, update
the version number of this library in :file:`lib/configure.ac`.
* Update table of supported versions in :file:`SECURITY.md`.
Look at previous release commit, like :ghcommit:`3b68dee7`, to view the lines
that should be modified and what content to write.
Perform commit:
.. code-block:: console
version=$(grep ^MODULES_RELEASE version.inc.in | cut -d ' ' -f 3)
git commit -a -m "Release of version $version"
Tag version:
.. code-block:: console
git tag v$version
Build and test release
----------------------
The build and test of the new release is handled by the :file:`script/mrel`
script. This utility creates the distribution archives, test these artifacts
and push to personal repository to run CI.
:file:`script/mrel` is made to be run on a Fedora system. It also build and
test install of RPM package and run remote build on Koji infrastructure.
:file:`script/mrel` asks when initializing for sudo rights (to remove local
``module`` installations prior running build and test), and for a personal
remote GitHub repository (to trigger online CI).
.. code-block:: console
script/mrel
.. note:: As it tests the different artifacts through running the
non-regression test suite, the execution of :file:`script/mrel` takes a lot
of time (more than 1 hour).
If script fails, its full output can be analyzed in :file:`mrel.out` log file.
This log file may be removed if no error occurs:
.. code-block:: console
rm mrel.out
Save a copy of the generated distribution files (adapt ``RELEASE_DIR`` to fit
your local setup):
.. code-block:: console
RELEASE_DIR=~/devel/modules-releases
cp modules-$version{.tar.bz2,.tar.gz,-win.zip} $RELEASE_DIR/
ls -lh $RELEASE_DIR/modules-$version{.tar.bz2,.tar.gz,-win.zip}
Publish release
---------------
Publication of the new release is handled by the :file:`script/mpub` script.
This tool pushes to online repositories (GitHub and SourceForge) and update
website (also pushed to both platforms).
:file:`script/mpub` asks when initializing for upstream remote GitHub
repository and it expects that valid credential to connect to SourceForge via
SFTP is available.
.. code-block:: console
script/mpub
If script fails, its full output can be analyzed in :file:`mpub.out` log file.
This log file may be removed if no error occurs:
.. code-block:: console
rm mpub.out
Now the website should mention the new release on the *Download* link. Stable
target of online document should also point to the new release. It may be
verified at:
* https://envmodules.io
* https://modules.readthedocs.io/en/stable/NEWS.html
Change *Default Download* on `SourceForge Files`_ page. Set the ``.tar.gz``
dist ball of the new release as the new default.
.. _SourceForge Files: https://sourceforge.net/projects/modules/files/Modules/
Close milestone on GitHub at https://github.com/envmodules/modules/milestones
Create release on GitHub at https://github.com/envmodules/modules/releases/new:
* Release title is bare version number ``X.Y.Z``
* Attach ``.tar.gz``, ``.tar.bz2`` and ``-win.zip`` artifacts to the release
* Build release description based on :file:`NEWS.rst` content:
.. code-block:: console
major_version=$(cut -d '.' -f 1 <<< "$version")
minor_version=$(cut -d '.' -f 2 <<< "$version")
previous_version="$major_version.$((minor_version - 1))"
grep -B1000 ".. _$previous_version release notes:" NEWS.rst | grep -A1000 -- "--------------------------" >NEWS.new
nb_lines=$(wc -l NEWS.new| cut -d ' ' -f 1)
sed -i -e "1,2d;$((nb_lines-3)),\$d" NEWS.new
sed -i -z -e "s/\n / /g" -e "s/\n / /g" -e 's/:option://g' -e 's/:mfcmd://g' -e 's/:subcmd://g' -e 's/:file://g' -e 's/:ref://g' -e 's/:mfcmd://g' -e 's/:mconfig://g' -e 's/:instopt://g' -e 's/:mfvar://g' -e 's/:envvar://g' -e 's/:command://g' -e 's/:sitevar://g' -e 's/``/`/g' NEWS.new
Check resulting :file:`NEWS.new` to adapt RST code for boxes, links, codes
(especially cleaning those containing ``\<`` or ``\>``) and make them valid
MarkDown code.
.. vim:set tabstop=2 shiftwidth=2 expandtab autoindent:
|
