2023-01-05 20:25:55 +08:00
|
|
|
/**************************************************************************/
|
|
|
|
|
/* version.h */
|
|
|
|
|
/**************************************************************************/
|
|
|
|
|
/* This file is part of: */
|
|
|
|
|
/* GODOT ENGINE */
|
|
|
|
|
/* https://godotengine.org */
|
|
|
|
|
/**************************************************************************/
|
|
|
|
|
/* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
|
|
|
|
|
/* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur. */
|
|
|
|
|
/* */
|
|
|
|
|
/* Permission is hereby granted, free of charge, to any person obtaining */
|
|
|
|
|
/* a copy of this software and associated documentation files (the */
|
|
|
|
|
/* "Software"), to deal in the Software without restriction, including */
|
|
|
|
|
/* without limitation the rights to use, copy, modify, merge, publish, */
|
|
|
|
|
/* distribute, sublicense, and/or sell copies of the Software, and to */
|
|
|
|
|
/* permit persons to whom the Software is furnished to do so, subject to */
|
|
|
|
|
/* the following conditions: */
|
|
|
|
|
/* */
|
|
|
|
|
/* The above copyright notice and this permission notice shall be */
|
|
|
|
|
/* included in all copies or substantial portions of the Software. */
|
|
|
|
|
/* */
|
|
|
|
|
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
|
|
|
|
|
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
|
|
|
|
|
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
|
|
|
|
|
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
|
|
|
|
|
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
|
|
|
|
|
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
|
|
|
|
|
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
|
|
|
|
|
/**************************************************************************/
|
2018-01-05 07:50:27 +08:00
|
|
|
|
2020-03-25 18:10:34 +08:00
|
|
|
#ifndef VERSION_H
|
|
|
|
|
#define VERSION_H
|
2019-12-01 00:22:22 +08:00
|
|
|
|
2018-09-12 00:13:45 +08:00
|
|
|
#include "core/version_generated.gen.h"
|
2017-04-11 05:08:19 +08:00
|
|
|
|
Refactor version macros and fix related bugs
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
2018-02-24 02:48:49 +08:00
|
|
|
// Godot versions are of the form <major>.<minor> for the initial release,
|
|
|
|
|
// and then <major>.<minor>.<patch> for subsequent bugfix releases where <patch> != 0
|
|
|
|
|
// That's arbitrary, but we find it pretty and it's the current policy.
|
|
|
|
|
|
|
|
|
|
// Defines the main "branch" version. Patch versions in this branch should be
|
|
|
|
|
// forward-compatible.
|
|
|
|
|
// Example: "3.1"
|
2023-04-13 00:28:41 +08:00
|
|
|
#define VERSION_BRANCH _MKSTR(VERSION_MAJOR) "." _MKSTR(VERSION_MINOR)
|
2019-12-01 00:22:22 +08:00
|
|
|
#if VERSION_PATCH
|
Refactor version macros and fix related bugs
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
2018-02-24 02:48:49 +08:00
|
|
|
// Example: "3.1.4"
|
2023-04-13 00:28:41 +08:00
|
|
|
#define VERSION_NUMBER VERSION_BRANCH "." _MKSTR(VERSION_PATCH)
|
2019-12-01 00:22:22 +08:00
|
|
|
#else // patch is 0, we don't include it in the "pretty" version number.
|
|
|
|
|
// Example: "3.1" instead of "3.1.0"
|
2023-04-13 00:28:41 +08:00
|
|
|
#define VERSION_NUMBER VERSION_BRANCH
|
2019-12-01 00:22:22 +08:00
|
|
|
#endif // VERSION_PATCH
|
|
|
|
|
|
2019-02-17 20:38:52 +08:00
|
|
|
// Version number encoded as hexadecimal int with one byte for each number,
|
|
|
|
|
// for easy comparison from code.
|
|
|
|
|
// Example: 3.1.4 will be 0x030104, making comparison easy from script.
|
|
|
|
|
#define VERSION_HEX 0x10000 * VERSION_MAJOR + 0x100 * VERSION_MINOR + VERSION_PATCH
|
Refactor version macros and fix related bugs
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
2018-02-24 02:48:49 +08:00
|
|
|
|
|
|
|
|
// Describes the full configuration of that Godot version, including the version number,
|
|
|
|
|
// the status (beta, stable, etc.) and potential module-specific features (e.g. mono).
|
|
|
|
|
// Example: "3.1.4.stable.mono"
|
2023-04-13 00:28:41 +08:00
|
|
|
#define VERSION_FULL_CONFIG VERSION_NUMBER "." VERSION_STATUS VERSION_MODULE_CONFIG
|
Refactor version macros and fix related bugs
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
2018-02-24 02:48:49 +08:00
|
|
|
|
|
|
|
|
// Similar to VERSION_FULL_CONFIG, but also includes the (potentially custom) VERSION_BUILD
|
|
|
|
|
// description (e.g. official, custom_build, etc.).
|
|
|
|
|
// Example: "3.1.4.stable.mono.official"
|
2023-04-13 00:28:41 +08:00
|
|
|
#define VERSION_FULL_BUILD VERSION_FULL_CONFIG "." VERSION_BUILD
|
Refactor version macros and fix related bugs
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
2018-02-24 02:48:49 +08:00
|
|
|
|
|
|
|
|
// Same as above, but prepended with Godot's name and a cosmetic "v" for "version".
|
|
|
|
|
// Example: "Godot v3.1.4.stable.official.mono"
|
2023-04-13 00:28:41 +08:00
|
|
|
#define VERSION_FULL_NAME VERSION_NAME " v" VERSION_FULL_BUILD
|
2019-12-01 00:22:22 +08:00
|
|
|
|
2022-02-09 03:50:37 +08:00
|
|
|
// Git commit hash, generated at build time in `core/version_hash.gen.cpp`.
|
|
|
|
|
extern const char *const VERSION_HASH;
|
|
|
|
|
|
2020-03-25 18:10:34 +08:00
|
|
|
#endif // VERSION_H
|
