Skip to content

Fix update-version.sh to remove leading zeros. #1003

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: branch-25.08
Choose a base branch
from

Conversation

mythrocks
Copy link
Contributor

This commit fixes an error in how version strings are replaced in the C API header.

Bumping the version to 25.08 causes the minor version to be written as "08" instead of "8", producing an invalid octal number.

This commit fixes the error in the script, and also bumps the versions in the C API, documentation, and workflow yamls.

This commit fixes an error in how version strings are replaced in the C
API header.

Bumping the version to 25.08 causes the minor version to be written as
"08" instead of "8", producing an invalid octal number.

This commit fixes the error in the script, and also bumps the versions
in the C API, documentation, and workflow yamls.
@mythrocks mythrocks self-assigned this Jun 10, 2025
@mythrocks mythrocks requested review from a team as code owners June 10, 2025 23:27
@mythrocks mythrocks requested a review from bdice June 10, 2025 23:27
@mythrocks mythrocks added bug Something isn't working non-breaking Introduces a non-breaking change labels Jun 10, 2025
@mythrocks
Copy link
Contributor Author

That the yaml files needed updating on branch-25.08 came as a surprise. I'd appreciate if someone familiar with them reviewed that change closely.

Comment on lines 23 to +25
static const uint16_t CUVS_VERSION_MAJOR = 25;
static const uint16_t CUVS_VERSION_MINOR = 06;
static const uint16_t CUVS_VERSION_PATCH = 00;
static const uint16_t CUVS_VERSION_MINOR = 8;
static const uint16_t CUVS_VERSION_PATCH = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than hard-coding these numbers in a C header, please consider generating them at CMake configure time with configure_file().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I haven't grokked your suggestion properly.

When update-version.sh is run, we would like for version-strings across all artifacts to be changed. For instance, update-version.sh 25.10 should cause the C API to return 25, 8, 0 as appropriate.

Should update-version.sh now change our CMake files, instead of directly changing c_api.h?

@cjnolet
Copy link
Member

cjnolet commented Jun 12, 2025

@mythrocks

I think the update_version.sh does change the cmake files, doesn't it? I think the suggest was just to have cmake update the c header, rather than relying on update_versions to do it. Honestly, i could go either way with this, so it doesn't matter a ton to me- so long as we aren't forced to update anything manually.

@mythrocks
Copy link
Contributor Author

(I'll fix the copyright dates shortly.)

@mythrocks
Copy link
Contributor Author

I think the update_version.sh does change the cmake files, doesn't it?

Not directly. It seems to update the VERSION file, and then CMake does its bit based on the VERSION.

so long as we aren't forced to update anything manually.

I've gotten an idea of how @KyleFromNVIDIA would prefer this were fixed. I'll try incorporate that change ASAP.

Copy link

copy-pr-bot bot commented Jun 13, 2025

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ci cpp non-breaking Introduces a non-breaking change
Projects
Development

Successfully merging this pull request may close these issues.

3 participants