chore: rename version variables for clarity#2123
Conversation
- Updated all references of `highestFinalVersion` to `highestPreviousVersion` for improved clarity and alignment with terminology. - Adjusted variable names, function names, and documentation across multiple scripts and workflows. - Ensured all tests reflect the new naming convention and maintain backward compatibility. - Change impacts workflows related to release preparation and finalization, improving code readability and consistency. Signed-off-by: Fabian Burth <fabian.burth@sap.com>
… `newReleaseVersion` - Updated all references to `finalTag` and `finalVersion` across scripts, workflows, and tests to use `newReleaseTag` and `newReleaseVersion`. - Adjusted variable names, function names, and documentation for clarity and alignment with new naming conventions. - Ensured all test cases follow the updated terminology to maintain consistency and backward compatibility. - Improved workflow readability and reduced ambiguity in release lifecycle-related scripts. Signed-off-by: Fabian Burth <fabian.burth@sap.com>
… `newReleaseVersion` - Updated all references to `finalTag` and `finalVersion` in scripts and workflows. - Renamed variables, functions, and documentation to reflect the new naming. - Improved clarity of workflows related to release processes by adopting consistent terminology. - Ensured backward compatibility by testing the changes thoroughly. Signed-off-by: Fabian Burth <fabian.burth@sap.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR renames release pipeline terminology from "final" to "new release" across CI workflows and scripts, updating function names, environment variables, parameters, and workflow outputs to use Changes
Sequence Diagram(s)(omitted — changes are renames/parameter updates without new multi-component control-flow) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Signed-off-by: Fabian Burth <fabian.burth@sap.com>
Signed-off-by: Fabian Burth <fabian.burth@sap.com>
- Renamed output labels for clarity: - "Latest Stable" -> "Previous Base Version" - "Latest RC" -> "Previous Base RC Version" - "Next RC Version" -> "Next Base RC Version" - Updates align naming conventions across the script with recent variable name changes. - Improves readability and reduces ambiguity in versioning-related output. Signed-off-by: Fabian Burth <fabian.burth@sap.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/scripts/release-versioning.js (1)
20-40: Variable renames look good, but consider aligningcomputeNextVersionsparameter names.The renamed variables (
previousBaseVersion,previousBaseRcVersion) improve clarity. However, thecomputeNextVersionsfunction signature on line 141 still useslatestStableTagandlatestRcTagas parameter names, which creates an inconsistency with the caller's variable names and the PR's goal of clearer naming.♻️ Optional: Align parameter names in `computeNextVersions`
-export function computeNextVersions(basePrefix, latestStableTag, latestRcTag, bumpMinorVersion) { +export function computeNextVersions(basePrefix, previousBaseVersionTag, previousBaseRcVersionTag, bumpMinorVersion) {Note: This would require updating the internal references within the function as well.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/scripts/release-versioning.js around lines 20 - 40, Rename the parameters in computeNextVersions from latestStableTag and latestRcTag to previousBaseVersion and previousBaseRcVersion (or vice-versa to match caller), and update all internal references inside computeNextVersions accordingly so the parameter names align with the renamed variables used at the call site (previousBaseVersion, previousBaseRcVersion) where computeNextVersions(basePrefix, previousBaseVersion, previousBaseRcVersion, false) is invoked.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/scripts/release-versioning.js:
- Around line 20-40: Rename the parameters in computeNextVersions from
latestStableTag and latestRcTag to previousBaseVersion and previousBaseRcVersion
(or vice-versa to match caller), and update all internal references inside
computeNextVersions accordingly so the parameter names align with the renamed
variables used at the call site (previousBaseVersion, previousBaseRcVersion)
where computeNextVersions(basePrefix, previousBaseVersion,
previousBaseRcVersion, false) is invoked.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 87765533-57d6-4ca4-9e71-a7fd88727206
📒 Files selected for processing (2)
.github/scripts/publish-final-release.test.js.github/scripts/release-versioning.js
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/scripts/publish-final-release.test.js
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it Highest Final Version and Final Version were quite hard to intuitively understand without additional documentation. This PR introduces a clearer naming scheme here. #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Contributes to open-component-model/ocm-project#971 #### Testing ##### How to test the changes <!-- Required files to test the changes: .ocmconfig ```yaml type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: "~/.docker/config.json" ``` Commands that test the change: ```bash ocm get cv xxx ocm transfer xxx ``` --> ##### Verification - [ ] I have tested the changes locally by running `ocm` --------- Signed-off-by: Fabian Burth <fabian.burth@sap.com> Co-authored-by: Jakob Möller <jakob.moeller@sap.com> (cherry picked from commit 81fba63)
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it Highest Final Version and Final Version were quite hard to intuitively understand without additional documentation. This PR introduces a clearer naming scheme here. #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Contributes to open-component-model/ocm-project#971 #### Testing ##### How to test the changes <!-- Required files to test the changes: .ocmconfig ```yaml type: generic.config.ocm.software/v1 configurations: - type: credentials.config.ocm.software repositories: - repository: type: DockerConfig/v1 dockerConfigFile: "~/.docker/config.json" ``` Commands that test the change: ```bash ocm get cv xxx ocm transfer xxx ``` --> ##### Verification - [ ] I have tested the changes locally by running `ocm` --------- Signed-off-by: Fabian Burth <fabian.burth@sap.com> Co-authored-by: Jakob Möller <jakob.moeller@sap.com> Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
What this PR does / why we need it
Highest Final Version and Final Version were quite hard to intuitively understand without additional documentation. This PR introduces a clearer naming scheme here.
Which issue(s) this PR fixes
Contributes to open-component-model/ocm-project#971
Testing
How to test the changes
Verification
ocm