Make version number accessible in code

[knatten]

This is just a suggestion, feel free to decline this or let me know if you prefer doing it in another way, such as with a shell script or Python or whatever. Or simply hard coding the version number in some header file.

Note that this PR conflicts with #46. If that one gets accepted, I'll rebase this one on master.

---

We're already making versioned releases, so let's make that version number available in code.

There are many ways to do this, such as release scripts etc. I chose a very simple CMake solution because the project is already using CMake and I didn't want to introduce a dependency on a new language.

Since we're not actually building releases anywhere, but just release the source code from the repo, I had to generate the version file inside the source tree. The person releasing will then have to commit both CMakeLists.txt and include/NamedType/version.hpp when bumping the version. (As well as tagging the commit, as before.)

One downside of this approach is that there is no way to detect whether you're using the actual x.y.z release, or if you just cloned the repo some time after x.y.z was released and the version number hasn't been bumped yet. This could have been solved by adding a "preview" suffix or something like that, which is removed in official releases. But I think that would complicate this code, and the release procedure too much for this project. And it will anyway not be a issue for users who stick to the official releases only.

[joboccara]

For my understanding, is this technique for handling versions from code common practice? Also, what is the expected usage of accessing version numbers through code?

[knatten]

For my understanding, is this technique for handling versions from code common practice?

I'm not that well versed in the world of libraries, but something similar to this seems to be common in my experience.

Catch does

#define CATCH_VERSION_MAJOR 2
#define CATCH_VERSION_MINOR 13
#define CATCH_VERSION_PATCH 0

Boost does (:astonished:) :

//  BOOST_VERSION % 100 is the patch level
//  BOOST_VERSION / 100 % 1000 is the minor version
//  BOOST_VERSION / 100000 is the major version
#define BOOST_VERSION 107400

In Zivid where I work, we do:

#define ZIVID_CORE_VERSION_MAJOR   2
#define ZIVID_CORE_VERSION_MINOR   0
#define ZIVID_CORE_VERSION_PATCH   0
#define ZIVID_CORE_VERSION_BUILD   "7c4918cf-14"
#define ZIVID_CORE_VERSION   "2.0.0+7c4918cf-14"

Also, what is the expected usage of accessing version numbers through code?

Some uses:

• Constexpr if based on which version of the library is used (or ifdef if you don't have constexpr if yet, which is why I went with #define instead of constexpr int or something
• Print versions of used libraries to a log or to the user
• My use case right now: There is a bug with unary operators in NamedType 1.1.0. It has been fixed, but the fix has not been released yet. I needed to add a workaround in our code in the mean time, which I want to make sure we delete when we upgrade to 1.2.0. So I wanted to do static_assert(NAMED_TYPE_VERSION_MAJOR == 1 && NAMED_TYPE_VERSION_MINOR == 1, "Delete this workaround when we upgrade to NamedType 1.2.0" );

[knatten]

Btw: I added a test to ensure the macros are defined, rebased on master, and updated the commit message a bit.

[joboccara]

Ok, I see. It seems to me there is still a pending comment in the code review, could you please have a look at it?

[knatten]

It seems to me there is still a pending comment in the code review, could you please have a look at it?

Which comment are you talking about? I can't see any?

[joboccara]

I seemed to have sent it, can you see it now?

[joboccara]

Great, thanks for this!

[knatten]

Thanks for accepting it! :)