Guidescan versioning and release process

[vineetbansal]

This setup is very similar to what I've used in the past for other C++ projects when it comes to versioning and release, and I think may work well here. Of course suggestions are welcome!

The basic idea is:

• As an example, cmake .. -DGUIDESCAN_VERSION=v2.0.3 will burn the v2.0.3 in a header file, which is then reported by guidescan --version

• A git tag (e.g. v2.0.3) that is pushed upstream, or an explicit release made on the GitHub page will trigger a CI workflow, which will:

  • Generate a .tar.gz for the binary distributions of Guidescan (for Linux and MacOS), which has the guidescan binary (in a bin/ folder) which reports the correct --version, the headers (in an include/ folder), and the scripts in a scripts/ folder. Of course we can add more stuff in there if desired. I think a shared library for guidescan once it becomes available will be a good addition here.
  • Generate .zip and .tar.gz files for source distributions of Guidescan. This is essentially a snapshot of the code when the release was made, in case users want to download and build a particular guidescan version themselves.

  I was getting errors building sdsl on Windows so I haven't included windows in the build matrix here. If that's critical, we can perhaps tackle that as a separate issue.

[schmidt73]

This seems reasonable. Should we create a document that describes features implemented in future versions? It might be a pain for people working on the project to update this document.

[vineetbansal]

You mean like a changelog? In the past I've used Github Releases, whenever I do make a release, to make notes on what's new in a particular version. Unless we maintain a changelog separately somewhere (which i don't think is the case). I might be misunderstanding the question here though (not sure what you mean by "this document"..)

[schmidt73]

That is what I mean! Github Releases sounds like a good plan to make notes on the version to version changes.