Start versioning and releasing

[hajduakos]

We should consider starting some versioning for Gazer. I suggest semantic versioning (e.g., v1.2.3), similarly to Boogie or Theta. What do you think @sallaigy?

[sallaigy]

Sounds good to me. Do you have a specific release procedure or toolchain (e.g. GitHub actions) in mind?

[hajduakos]

Nothing in particular in my mind. With Theta we have roughly the following process:

• We develop features/bugfixes on separate branches.
• Before merging the branch (as a PR), we bump the major/minor/patch version.
• After the merge, I create the corresponding GH release with some description (manually).
  • For major/minor, I also build and upload the binaries (manually). For patches, I do not do it currently.

So this is mostly a manual process, but so far it did not require too much effort so I'm fine with it. But if you have some automation in mind, let me know.

[hajduakos]

The technical aspect is that this version number should be stored in some class / global variable / config file, so that command line tools can provide a -version flag.

[AdamZsofi]

I think Gazer already has a version flag, it just needs a bit of updating - LLVM has a SetVersionPrinter function, which is used in the main functions and it takes a function as a parameter, which should output the version info.

In Gazer this is implemented here. Currently the info is hardcoded and outputs "Gazer 0.1 LLVM 9.0". Maybe it would look a bit nicer, if the FrontendConfig or the FrontendConfigWrapper could store the version numbers, but I don't think it needs any other changes to start versioning.

[hajduakos]

Seems good, both the bmc and the theta backends use this, so this is the only place where modification is needed. I would suggest to start with 1.0.0 now, and then before merging PRs or branches, we can bump this number. We should also create tags/releases on GitHub, where we might upload the binaries (but not necessarily). I think we should start this ASAP, and then later we can improve (e.g., with automation). What do you think @sallaigy ?

[hajduakos]

Having some versioning is needed really soon for SV-Comp.

[sallaigy]

Sounds good to me - PR #51 introduces basic versioning in which versions would only need to be updated in the root CMakeLists file. The PR also bumps the version number to a new official 1.0.0 \o/