Add library version

[SteffenL]

I am submitting this PR with #707 in mind. The initial work was ripped out of #766 but I decided to rewrite it.

Feedback would be most welcome so that we do this properly the first time.

Which version would you prefer to set in this PR? It is currently set to 0.11.0 but 0.10.0 could also be a candidate.

Would you prefer a default value for WEBVIEW_VERSION_PRE_RELEASE?

Closes #442.

Example 1

Program:

// These preprocessor definitions are merely for demonstration purposes.
#define WEBVIEW_VERSION_MAJOR 1
#define WEBVIEW_VERSION_MINOR 2
#define WEBVIEW_VERSION_PATCH 3
#define WEBVIEW_VERSION_PRE_RELEASE "-dev"
#define WEBVIEW_VERSION_BUILD_METADATA "+gdd38be8"

#include "webview.h"
#include <iostream>

int main() {
  auto vi = webview_version();
  std::cout << "major: " << vi->major << "\n"
            << "minor: " << vi->minor << "\n"
            << "patch: " << vi->patch << "\n"
            << "version: " << vi->version << vi->pre_release
            << vi->build_metadata << "\n"
            << std::flush;
  return 0;
}

Output:

major: 1
minor: 2
patch: 3
version: 1.2.3-dev+gdd38be8

Example 2

Program:

#include "webview.h"
#include <iostream>

int main() {
  auto vi = webview_version();
  std::cout << "major: " << vi->major << "\n"
            << "minor: " << vi->minor << "\n"
            << "patch: " << vi->patch << "\n"
            << "version: " << vi->version << vi->pre_release
            << vi->build_metadata << "\n"
            << std::flush;
  return 0;
}

Output:

major: 0
minor: 11
patch: 0
version: 0.11.0

[justjosias]

I like your work on this. One question: Is it possible to make a simple comparison to determine whether or not the version is greater or smaller than the expected one? If not, do you think that would be a useful feature? As it stands, checking versions appears to require comparing each of the values separately.

[SteffenL]

@justjosias There are a few cases where I imagine comparing versions would be useful:

• User wants to check the version of the library header using a macro (see b4e10e58b02495e8d6dcd9617634e536fdc60bd2).
• User wants to check the version baked a shared library using webview_version().
• Shared library wants to check the version of the user's header.

Since there are different ways to do this, please let me know what you are thinking in detail.

Out of the points above, I think the most useful one would be the library internally checking the user-supplied version at runtime to make sure that the user's header (or any version really) is compatible with the library or to change the library's behavior based on the supplied version.

Anything can certainly be implemented but we can also consider implementing that when we actually need it.

[Winterreisender]

Thank you for your work on this! I think this would be very useful for me since I need to check if user's dll/so/dylib is compatible with my code. If the users are using an old dll, for example, they only copied new exe but forget to copy new dll, I need to find it out. Personally, I prefer 0.10.0 but it really doesn't matter. The more important thing for me may be making sure that two version with same minor version have compatible API for the use case mentioned above.

[SteffenL]

@Winterreisender For the record, I think that you are thinking from library bindings' point of view. It is a good use case.

For example, if one wanted to check whether the shared library's version is at least a certain version then it could look something like this:

bool is_webview_version_at_least(unsigned int major, unsigned int minor) {
  const webview_version_info_t *v = webview_version();
  if (v->major == major) {
    return v->minor >= minor;
  }
  return v->major > major;
}

I think this might be best left to bindings to implement in their native language.

[SteffenL]

I had some doubts about the previously approved work and it took me a while to be able to resume working on this. I made a few more changes and if there are no immediate complaints then I will merge this. I'll give it a few days.

The changes consist of cleanup, renames, and splitting of code that might be used in future work. The version info struct has fixed-size char arrays now instead of pointers to const char to make the struct self-contained, easy for library users to copy if needed, and is a bit safer for library users to use since there are no pointers that could ever become invalid. Some time later we will need to compare versions and having the new struct might be a bit cleaner when the time comes.

[SteffenL]

@dandeto Thank you for taking a look at this!

[SteffenL]

PR #862 replaces this one due to the master branch reset.