Automate release process

[adbancroft]

This PR adds a GitHub action to prepare the code base for a release (updating the version number in various files) and generates a draft release with the appropriate tag.

Usage:

1. Manually run the 'Create draft release' workflow/action
2. Follow the output link to the created draft release. E.g.
   
3. Edit the release notes & publish

This codifies tribal knowledge & will avoid issues like #108

[kimwalisch]

@adbancroft Can you please add a RELEASE.md which explains the release procedure using e.g. a short list of bullet points. The goal of this file should be that new maintainers can easily figure out how to do a new release without any help needed from previous maintainers (since they might not be around anymore).

[kimwalisch]

In my opinion it would also be better to hardcode the version number of LIBDIVIDE_VERSION in libdivide.h and update it using your release script. Your macro string concatenation code is complicated, it might potentially cause problems when libdivide.h is imported into programming languages other than C/C++.

[adbancroft]

Your macro string concatenation code is complicated, it might potentially cause problems when libdivide.h is imported into programming languages other than C/C++.

• It's a very widely used C pre-processor technique: the GCC manual describes it at least as far back as v2.95 (released in 1999)
• I'd prefer to keep the code DRY - this seemed like the simplest approach.

Is there a specific use case you have in mind?

[kimwalisch]

Is there a specific use case you have in mind?

We should try to keep the libdivide.h code as simple as possible and only add additional complexity if this improves libdivide.h in a meaningful way (e.g. improves performance). If I understand your pull request correctly then it is possible to move the complicated code related to the LIBDIVIDE_VERSION macro into your release script which would allow to get rid of all your string concatenation macros.

It's a very widely used C pre-processor technique: the GCC manual describes it at least as far back as v2.95 (released in 1999)

You as proficient C/C++ programmer might easily understand this code. But many other programmers will not immediately understand this code. So why add this complexity to libdivide.h when there is a less complex alternative solution?