Update version identifiers after a release.

[dbrnz]

Version 0.6.3 was released on 11 November 2024 and although some significant code changes have been made since, CMakeLists.txt (at the HEAD of main) still has _PROJECT_VERSION set at 0.6.3, .

Shouldn't _PROJECT_VERSION be updated immediately after a release is made? With PROJECT_DEVELOPER_VERSION also being updated? And shouldn't the version now resolve to 0.7.0-rc.1??

[agarny]

That's the thing, no version has been released in a very, very long time. Our current release process relies on the ABI's local infrastructure and... well, it's broken, unavailable, or whatever. So, I am personally waiting on @hsorby doing something about it...

[hsorby]

I am working on moving the release process to GitHub Actions, the currently unavailable Buildbot based release process did a lot of work checking and preparing for a release. I’m plugging away at this as a matter of urgency.

[hsorby]

As to the update of the version number, this definitely shouldn’t be 0.7.0-rc.1.
You cannot say that the next release will be a version 0.7.0 release candidate. At best you can say that the current code 0.6.3.post.1. The original idea was to determine the repository status from the last version tag, much like what pyproject.toml does for Python packages using SCM.

[dbrnz]

My main point is that it definitely shouldn't have stayed at 0.6.3. Given though that code from HEAD is being deployed into (semi-)released applications (e.g. simlulationvuer via libopencor), and that HEAD contains some significant changes from the 0.6.x, shouldn't the current version be at least 0.7.0-alpha.1??

[agarny]

I am working on moving the release process to GitHub Actions, the currently unavailable Buildbot based release process did a lot of work checking and preparing for a release. I’m plugging away at this as a matter of urgency.

Thanks Hugh!