In camp/config.hpp.in, version numbers are generated like so:
#define CAMP_VERSION_MAJOR @camp_VERSION_MAJOR@
#define CAMP_VERSION_MINOR @camp_VERSION_MINOR@
#define CAMP_VERSION_PATCH @camp_VERSION_PATCH@
#define CAMP_VERSION \
(CAMP_VERSION_MAJOR * 1000000) + (CAMP_VERSION_MINOR * 1000) \
+ (CAMP_VERSION_PATCH)
In a concrete example:
#define CAMP_VERSION_MAJOR 2025
#define CAMP_VERSION_MINOR 12
#define CAMP_VERSION_PATCH 0
This results in CAMP_VERSION being 2025012000, which looks really weird and isn't easy to process mentally. If we took out one order of magnitude for CAMP_VERSION_MAJOR, it would be better (e.g. 202512000). I'd like it even better if it looked like 20251200 or 20260700. To get that, we'd have to change the definition of CAMP_VERSION to the following:
#define CAMP_VERSION \
(CAMP_VERSION_MAJOR * 10000) + (CAMP_VERSION_MINOR * 100) \
+ (CAMP_VERSION_PATCH)
The biggest downside would be that you couldn't use code like the following because the version number would actually decrease from 2026.07.0 to 2026.07.1 or anything newer:
#if CAMP_VERSION >= 20260701
m_async_resource.wait_for(m_wait_for_event);
#else
m_async_resource.wait_for(&m_wait_for_event);
#endif
In camp/config.hpp.in, version numbers are generated like so:
In a concrete example:
This results in CAMP_VERSION being 2025012000, which looks really weird and isn't easy to process mentally. If we took out one order of magnitude for CAMP_VERSION_MAJOR, it would be better (e.g. 202512000). I'd like it even better if it looked like 20251200 or 20260700. To get that, we'd have to change the definition of CAMP_VERSION to the following:
The biggest downside would be that you couldn't use code like the following because the version number would actually decrease from 2026.07.0 to 2026.07.1 or anything newer: