Start versioning and releasing about gazer HOT 7 CLOSED

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/

from gazer.

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

from gazer.

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.

from gazer.

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.

from gazer.

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.

from gazer.

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 ?

from gazer.

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

from gazer.