Update cbmc config to version 5.18.0.

[NlightNFotis]

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

Merging #5569 (d52cf57) into develop (df544aa) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #5569   +/-   ##
========================================
  Coverage    69.28%   69.28%           
========================================
  Files         1241     1241           
  Lines       100436   100436           
========================================
  Hits         69589    69589           
  Misses       30847    30847           

Flag	Coverage Δ
cproversmt2	43.05% <ø> (ø)
regression	66.24% <ø> (ø)
unit	32.22% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update df544aa...d52cf57. Read the comment docs.

[tautschnig]

Can someone explain to me why the codecov/project job is failing here (well, actually I'm seeing it failing on all other PRs as well, unless I'm mistaken)? Edit: seemingly that's not longer failing now. Whatever the magic.

[tautschnig]

It would be nice if the release commit could at least include some statement of why marking this particular state of develop as the next release is the right thing. If it's "It's Thursday, so we release" then that's ok as well, but right now it feels entirely random.

[NlightNFotis]

Hi @tautschnig. The regular release process is indeed every two weeks - it's documented in https://github.com/diffblue/cbmc/blob/develop/doc/ADR/release_process.md.

We felt that every two weeks was a good compromise between a release cadence that's often enough to make sure we ship new features, but it's not very tight (for example every week) so that we come out with releases that don't contain new features or bug releases. Do you think this information should go somewhere else?

[tautschnig]

Hi @tautschnig. The regular release process is indeed every two weeks - it's documented in https://github.com/diffblue/cbmc/blob/develop/doc/ADR/release_process.md.

We felt that every two weeks was a good compromise between a release cadence that's often enough to make sure we ship new features, but it's not very tight (for example every week) so that we come out with releases that don't contain new features or bug releases. Do you think this information should go somewhere else?

I think that's perfectly good, but it would be nice if doing git log could in future also provide some insight, for example by not having an empty body of the commit message :-) Really, "Bi-weekly release" could even do. But it's not a big deal, just nice to have.