bumped version to 2.11#4751
Conversation
| release notes for cppcheck-2.10 | ||
| release notes for cppcheck-2.11 | ||
|
|
||
| - the deprecated Makefile option SRCDIR is no longer accepted | ||
| - if the file provided via "--file-list" cannot be opened it will now error out | ||
| - add command-line option "--disable=<id>" to individually disable checks | ||
| - added CMake option BUILD_CORE_DLL to build lib as cppcheck-core.dll with Visual Studio | ||
| - Windows binaries currently default to the "win32A" and "win64" platform respectively. Starting with Cppcheck 2.13 they will default to 'native' instead. Please specify '--platform=win32A' or '--platform=win64' explicitly if you rely on this. |
There was a problem hiding this comment.
Why not stack the release notes for each release rather removing the old notes in favor of the new one?
There was a problem hiding this comment.
The releasenotes are not well maintained. We just recently got into documenting things a bit better. But is is probably still subpar. @danmar usually provides some brief write-up on the GitHub/Trac release page but that varies greatly.
As we are doing a lot of work based on tickets and mainly do changes via PRs you have some implicit documentation based on that in GitHub and in Trac - see https://trac.cppcheck.net/milestone/2.10 for the current stable release.
|
@firewave @danmar sorry to jump in here (I did not find a way to create an issue for this project), but I want to raise that 2.11 did not marked as a release tag or git tag. Also I am not sure 2.10.1 is the intended latest release. Can you help clarifying it? Thanks!! relates to Homebrew/homebrew-core#123616 |
|
2.11 is the current dev version. 2.10.x is the latest version. For the patch releases there's only a temporary branch which will cease to exist when the next minor version is being released. Those are exclusively maintained by @danmar but if you have a pressing issue which is already fixed in head you can CC him on the PR/commit in question and ask for a backport so the next patch release will work out for you. The latest tag is always the current stable release and you should build upon that. So it is indeed 2.10.1 at the moment. I want to propose a change to the versioning to make things clearer but I wanted to do this along with a review of the release process so we don't miss any parts in the future like we have for the past few releases. Unfortunately I haven't gotten to that yet. |
| // After a release the DEVMINOR is incremented. MAJOR=x MINOR=y, DEVMINOR=y+1 | ||
|
|
||
| #define CPPCHECK_MAJOR 2 | ||
| #define CPPCHECK_MINOR 9 |
There was a problem hiding this comment.
I believe there is a misunderstanding here.
Latest stable release is 2.10
Therefore the CPPCHECK_VERSION should 2,10,99,0
So CPPCHECK_MINOR should be 10
And CPPCHECK_DEVMINOR should be 11
Then the CPPCHECK_VERSION_STRING will become "2.11 dev" .. that means "2.11 under development".
There was a problem hiding this comment.
It seems the intention with DEVMINOR was to hold the minor version under development. The goal of current development is to release 2.11.
There was a problem hiding this comment.
That would make more sense but then then the dev version would always have a higher version with the 2.10.x series and would seems like a newer version to use.
I would propose something I have used before a simpler approach to what GCC and Clang are doing.
x.y.0 - the dev version - 2.11.0
x.y.1 - the first stable release - 2.11.1
x.y.z - the following patch versions 2.11.2 etc.
x.a.0 - the next dev version - 2.12.0
As the .0is defined as the dev version there's no separate indicator necessary for it at all. It would also not break the parsable version by adding a string. It's also very straight forward to document and understand as it has precedence.
Integrating the commit hash for each more precise versions would also be possible.
There's the possibly of using the -PRERELEASE (do not remember 100% - need to look it up again) suffix which would be a valid parsable version. But for that we need a proper scripting approach - which should be easy work though (as I have done that before). Hence why I wanted to propose this after I reviewed the release process.
3 participants
We really need to improve/review/streamline the release steps.