Provide version checking functionality

[KangLin]

@seladb
The API was changed in #2056, but this project does not provide version checking functionality, which results in the application being unable to maintain compatibility(Supports both 25.05 and 24.09 etc)

Semantic Versioning: https://semver.org/

[seladb]

@KangLin there is a version in this project, you can find all versions here: https://pcapplusplus.github.io/versions
We're using CalVer instead of SemVer.

Unfortunately we didn't make a new release for almost a year, and the latest stable version is v25.05, which was released in May 2025.

The PR you're referring to was merged in Jan 2026 and is part of the next release, which we hope to create soon. Our "dev" version is v25.05+ until we create the next release.

PcapPlusPlus does provide an API to get the version which you can find here: https://pcapplusplus.github.io/api-docs/next/_pcap_plus_plus_version_8h.html

[KangLin]

@seladb Thank you for your reply.
The currently provided version information can be used for version checks during travel, but cannot be used for version checks during compilation. What I need is to perform version checks during compilation in order to achieve compatibility.
eg:

/*
   QT_VERSION is (major << 16) + (minor << 8) + patch.
*/
#define QT_VERSION      QT_VERSION_CHECK(QT_VERSION_MAJOR, QT_VERSION_MINOR, QT_VERSION_PATCH)
/*
   can be used like #if (QT_VERSION >= QT_VERSION_CHECK(4, 4, 0))
*/
#define QT_VERSION_CHECK(major, minor, patch) ((major<<16)|(minor<<8)|(patch))�

#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
    #include <QScreen>
#endif�

[seladb]

@KangLin we have the PCAPPLUSPLUS_VERSION macro but it's a string that's not very easy to parse in compile time... I guess we can add PCAPPLUSPLUS_VERSION_MAJOR and PCAPPLUSPLUS_VERSION_MINOR that would be integers 🤔

Feel free to add it if you have time 👍

[KangLin]

@seladb
Calver is only suitable for applications, while semver is more suitable for libraries.
What do you think?

[KangLin]

@seladb
Calver is only suitable for applications, while semver is more suitable for libraries.

[seladb]

Calver is only suitable for applications, while semver is more suitable for libraries.

It's debatable, there are many libraries that use CalVer, here are a few examples:

• DPDK
• Certifi
• Black Python formatter
• pip

PcapPlusPlus has used CalVer for almost a decade, I don't think or see a reason to suddenly change to SemVer

[KangLin]

Application changes will not affect others. Changes in the library's API will affect other libraries that depend on it.

Semver specifies:
1. MAJOR version when you make incompatible API changes
This may be the reason for the change.
Or there might be a better way to solve this issue?

[Dimi1010]

I suppose the YY (year) part of CalVer can be treated as Major version for API purposes and breaking changes?

Tho it isn't perfect as there may be years where the API doesn't have a breaking change but it would still counts as API break.

[Dimi1010]

Also, a potential schema I could see is breaking changes being introduced only on a new yearly version. And the in-year release versions to be kept API compatible with each other.

When a breaking change is introduced to master / dev, the working version is updated to the next year, with the month being 00+, if its not that already.

Essentially something like this:
25.04+ goes to 26.00+, on the first merged breaking change (+tag). Further breaking changes do not change the version if its already on 00+ minor, as that is considered unstable.

That would separate the cases where the master head is API compatible with the last stable release or not.

When a stable release it pushed after the breaking change, the month is updated.

Something like this:
(master head) 26.00+ -> 26.04 (release ver) -> 26.04+ (master head after release)

Note:
If multiple releases happen in the same month (hotfix or something), the following versions after the first have a patch number appended.

Example:
First version in April 26 = 26.04
Second version in April 26 = 26.04.1 or 26.04.2. Those are usually rare.

PS: Yes, this is a Frankenstein monster mix of CalVer and SemVer.

[seladb]

In essence, CalVer doesn't have a concept of major/minor versions which means users need to look in the release notes to find out the breaking changes. I think it's ok because:

• We don't create new releases very often
• We try to make as little breaking changes as possible
• We do our best to have a clear and verbose release notes which highlight the breaking changes

[seladb]

@KangLin I opened a draft PR that addresses it, please let me know what you think: #2118