[CDRIVER-5932] Simplify version calculations #1943
Conversation
fetch-source would pull sources from the repo, and then recalculate the current version and overwrite the VERSION_CURRENT file. We will rely on VERSION_CURRENT going forward. fetch-source also tried ot create a qualified name for the commit as $CURRENT_VERSION, but this was bugged and only included the commit hash on patch builds. We don't rely on this, so we'll go with just using the commit hash for now.
| find_package(Python COMPONENTS Interpreter) | ||
|
|
||
| set(_CALC_VERSION_PY "${CMAKE_CURRENT_LIST_DIR}/../calc_release_version.py") | ||
|
|
||
| #[[ | ||
| Attempts to find the current build version string. If VERSION_CURRENT exists | ||
| in the current source directory, uses that. Otherwise, runs calc_release_version.py |
There was a problem hiding this comment.
Revise out-dated comment.
| project. During development, this should be ``x.y.z-dev``. On release | ||
| branches, this will have the prerelease tag removed. |
There was a problem hiding this comment.
| project. During development, this should be ``x.y.z-dev``. On release | |
| branches, this will have the prerelease tag removed. | |
| project. During development, this should be ``x.y.z-dev``. On tagged commits, this will have the prerelease tag removed. |
With the current release workflow, VERSION_CURRENT is bumped on a release branch after a tag.
For a patch release: 1.2.3:
r1.2branch gets a1.2.3tagged commit withVERSION_CURRENT == 1.2.3.r1.2bumpsVERSION_CURRENTto1.2.4-dev.
For a minor release: 1.2.0:
r1.2branch gets a1.2.0tagged commit withVERSION_CURRENT == 1.2.0.r1.2bumpsVERSION_CURRENTto1.2.1-dev.masterbumpsVERSION_CURRENTto1.3.0-dev.
| 1. Manually update the ``NEWS`` and ``src/libbson/NEWS`` files with the content | ||
| from the release branch that we just published. Commit these changes to the | ||
| new branch. | ||
| 2. For a minor release, manually update the :file:`VERSION_CURRENT` file. Example |
There was a problem hiding this comment.
| 2. For a minor release, manually update the :file:`VERSION_CURRENT` file. Example | |
| 2. For a non-patch release, manually update the :file:`VERSION_CURRENT` file. Example |
I expect when 2.0 is released, VERSION_CURRENT on master will become 2.1.0-dev.
| new branch. | ||
| 2. For a minor release, manually update the :file:`VERSION_CURRENT` file. Example | ||
| if ``1.28.0`` was just released, update to ``1.29.0-dev``. | ||
| 3. Update the :file:`etc/prior_version.txt` file to contain the version that you |
There was a problem hiding this comment.
| 3. Update the :file:`etc/prior_version.txt` file to contain the version that you | |
| 3. For a non-patch release, update the :file:`etc/prior_version.txt` file to contain the version that you |
On master, I expect updating etc/prior_version.txt only applies for a non-patch release. Example: if 1.31.2 is released after 2.0.0, I expect etc/prior_version.txt on master to stay at 2.0.0 so the ABI compliance check continues to use 2.0.0 as the base to compare against.
On a release branch, I expect the post_release_bump release step can be extended to update etc/prior_version.txt.
There was a problem hiding this comment.
I think that the way to think of it is "the commit referred to by etc/prior_version.txt must be a direct ancestor of the commit where the update is made".
Refer: CDRIVER-5932
This changeset removes
calc_release_version.pyand uses thereof. Instead, we rely on the existingVERSION_CURRENTfile to indicate the version.We also add an
etc/prior_version.txt1 file that contains the version number (Git tag) of the most recent stable release. This is currently used byabi-compliance-checkto refer to the build against which it compares. If we can find a way to tweakabi-compliance-checkto not need this file, then this file can be deleted.The release process has been updated with steps on updating
etc/prior_version.txt. A new devdocs page was added to clarify the purpose ofVERSION_CURRENTandetc/prior_version.txt.Footnotes
Name subject to bikeshedding. ↩