@@ -11,25 +11,22 @@ The current process we follow through to make a new release is the following:
11
11
1 . At the point in time we want to make the release, we make a change to
12
12
` src/config.inc ` , and update the configuration variable ` CBMC_VERSION ` .
13
13
This is important as it informs the various tools of the current version
14
- of CBMC.
15
-
16
- (This needs to be pushed as a PR, and after it gets merged we move on to:)
17
-
18
- 2 . Then we make a ` git tag ` out of that commit, and push it to github. The
19
- tag needs to be of the form ` cbmc-<version> ` with version being a version
14
+ of CBMC. The commit message must then contain one of #major, #minor, or
15
+ #patch to inform the GitHub action that automatically creates a release tag.
16
+ The tag is of the form ` cbmc-<version> ` , with ` <version> ` being a version
20
17
number of the form of ` x.y.z ` , with ` x ` denoting the major version, ` y `
21
18
denoting the minor version, and ` z ` identifying the patch version (useful
22
19
for a hotfix or patch.)
23
20
24
21
At this point, the rest of the process is automated, so we don't need to do
25
22
anything more, but the process is described below for reference:
26
23
27
- 3 . ` .github/workflows/regular-release.yaml ` gets triggered on the ` push `
24
+ 2 . ` .github/workflows/regular-release.yaml ` gets triggered on the ` push `
28
25
of the tag, and creates a Github release of the version that was
29
26
described in thetag pushed (so, tag ` cbmc-5.15.20 ` is going to
30
27
create the release titled ` cbmc-5.15.20 ` on the release page).
31
28
32
- 4 . ` .github/workflows/release-packages.yaml ` gets triggered automatically
29
+ 3 . ` .github/workflows/release-packages.yaml ` gets triggered automatically
33
30
at the creation of the release, and its job is to build packages for
34
31
Windows, Ubuntu 18.04 and Ubuntu 20.04 (for now, we may support more
35
32
specific Ubuntu versions later) and attaches them (after it has finished
0 commit comments