Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #2118 +/- ##
========================================
Coverage 82.68% 82.68%
========================================
Files 332 332
Lines 59696 59696
Branches 12306 12585 +279
========================================
+ Hits 49358 49359 +1
+ Misses 9015 8950 -65
- Partials 1323 1387 +64
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@Dimi1010 this PR is still in draft, but I wanted to get your opinion on this approach |
|
|
||
| /// @def PCAPPLUSPLUS_VERSION | ||
| /// @brief Short version string (e.g., "25.05" for official release or "25.05+" for development) | ||
| #define PCAPPLUSPLUS_VERSION "25.05+" |
There was a problem hiding this comment.
It's possible to create this string using macros, but it'll be very complex, so maybe it's easier to keep it as is...
There was a problem hiding this comment.
I suppose we can manually set it.
A potential alternative is to have the cmake build system generate the version file, like it does with the package config files. I think that is generally more flexible and we would only need to change the version in the CMakeLists.
Also, do you think we should include the patch number in all versions? (eg. 25.05.0), so people always expect it if they decide to do magic with the version string?
There was a problem hiding this comment.
A potential alternative is to have the cmake build system generate the version file, like it does with the package config files. I think that is generally more flexible and we would only need to change the version in the CMakeLists.
@seladb Additional discussion may be needed separately, but I managed to get CMake to compile a version from the git tags. The versioning is based on the signature major.minor.patch.tweak.
It fetches the MAJOR, MINOR, PATCH from the most recent tag. (eg. last release)
It then calculates the Tweak version as the number of commits past the most recent tag the build is.
If we are precisely on the release commit, the tweak version will be 0 and the full version maj.min.patch.0, if we are 1 commit past it it will be maj.min.patch.1. This can then be used to determine official releases (tweak 0) vs nightly / dev builds (tweak != 0).
The solution will allow us to have rolling versions unique for each development build commit, so we don't have just a nebulous "DEV" version flag. For example the current master would be 25.05.0.201.
A extended version string can also be added with a commit hash, if we need to differentiate between commits on different branches, but I think most will be used from the master / dev line.
Dimi1010
left a comment
Dimi1010
left a comment
There was a problem hiding this comment.
Looks ok. I am a bit iffy on PCAPPLUSPLUS_VERSION_DEV, but I don't have any better ideas for it, so... 🤷
|
|
||
| /// @def PCAPPLUSPLUS_VERSION | ||
| /// @brief Short version string (e.g., "25.05" for official release or "25.05+" for development) | ||
| #define PCAPPLUSPLUS_VERSION "25.05+" |
There was a problem hiding this comment.
I suppose we can manually set it.
A potential alternative is to have the cmake build system generate the version file, like it does with the package config files. I think that is generally more flexible and we would only need to change the version in the CMakeLists.
Also, do you think we should include the patch number in all versions? (eg. 25.05.0), so people always expect it if they decide to do magic with the version string?
|
it is recommended to use Semantic format. the major for the API，the minor for year, the path for date. |
@KangLin I don't think we want to switch from CalVer to SemVer, at least not now |
3 participants
Addresses #2101.
This PR adds version macros and introduces a patch version in case we need it:
It also includes macros to compare versions, for example: