build: base version proposals on last release tag#2077
Conversation
The feature version audit compared against the PR base SHA (tip of dev), so each PR between releases proposed an additional bump on top of whatever dev already had, accumulating spurious version increments. Fix: in --pr-check mode, anchor prior_ver and commit gathering to the last semver release tag so a bump already applied by an earlier PR in the same release cycle satisfies the check. Retroactively reset all feature .ini versions to their v1.4.11 baseline and re-ran --apply-bumps to produce correct single-bump values for every feature with functional changes since release. Also add `* text=auto eol=lf` to .gitattributes to enforce LF at the git index level, complementing the existing pre-commit hook. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR adds a global .gitattributes LF normalization rule, updates Version metadata across many feature INI files (some bumps, many newline/EOF normalization changes), and modifies tools/feature_version_audit.py to support release-tag-scoped baseline comparisons and adjust commit/diff aggregation for release vs PR scopes. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant Script as "feature_version_audit.py"
participant Git
participant FS as "INI files"
CLI->>Script: run (normal or --pr-check)
alt --pr-check
Script->>Git: git tag --merged <base_ref> --list v*.*.* (get_latest_release_tag)
Git-->>Script: release_ref (or none)
Script->>Git: git diff --name-only <version_ref>..HEAD (release_changes)
else normal
Script->>Git: git tag --merged HEAD --list v*.*.* (get_latest_release_tag)
Git-->>Script: version_ref
Script->>Git: git diff --name-only <version_ref>..HEAD (release_changes)
end
Script->>FS: read feature INI files
Script->>Git: get_commits_for_file(..., version_ref) (aggregate release-scoped commits)
Git-->>Script: commit history per file
Script->>Script: compute prior_ver, pr_prior_ver, proposed_ver, needs_bump
Script->>CLI: output proposed version changes / report
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 |
|
No actionable suggestions for changed features. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tools/feature_version_audit.py`:
- Around line 689-699: The PR-mode logic uses get_latest_release_tag() to set
release_ref which currently returns the highest semver tag across the repo;
change it to resolve the latest release tag reachable from the target branch
history (base_ref) instead: when args.pr_check is true, call a new or modified
helper (e.g., get_latest_release_tag_for_ref(base_ref) or extend
get_latest_release_tag to accept a ref) that lists tags reachable from base_ref
and picks the newest semver among those, then set release_ref from that result
so prior_ver, release_changes and proposed bumps are anchored to the target
branch history rather than unrelated tags on other branches.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3935673d-f95f-42e8-aede-6bc138584ff8
📒 Files selected for processing (23)
.gitattributesfeatures/Cloud Shadows/Shaders/Features/CloudShadows.inifeatures/Dynamic Cubemaps/Shaders/Features/DynamicCubemaps.inifeatures/Extended Materials/Shaders/Features/ExtendedMaterials.inifeatures/Grass Collision/Shaders/Features/GrassCollision.inifeatures/Grass Lighting/Shaders/Features/GrassLighting.inifeatures/Hair Specular/Shaders/Features/HairSpecular.inifeatures/IBL/Shaders/Features/ImageBasedLighting.inifeatures/Linear Lighting/Shaders/Features/LinearLighting.inifeatures/Performance Overlay/Shaders/Features/PerformanceOverlay.inifeatures/Screen Space GI/Shaders/Features/ScreenSpaceGI.inifeatures/Screen-Space Shadows/Shaders/Features/ScreenSpaceShadows.inifeatures/Sky Sync/Shaders/Features/SkySync.inifeatures/Skylighting/Shaders/Features/Skylighting.inifeatures/Terrain Blending/Shaders/Features/TerrainBlending.inifeatures/Terrain Shadows/Shaders/Features/TerrainShadows.inifeatures/Unified Water/Shaders/Features/UnifiedWater.inifeatures/Upscaling/Shaders/Features/Upscaling.inifeatures/VR/Shaders/Features/VR.inifeatures/Volumetric Lighting/Shaders/Features/VolumetricLighting.inifeatures/Weather Editor/Shaders/Features/WeatherEditor.inifeatures/Wetness Effects/Shaders/Features/WetnessEffects.initools/feature_version_audit.py
|
✅ A pre-release build is available for this PR: |
get_latest_release_tag() previously listed all semver tags in the repo; a hotfix tag on an unrelated branch could become the baseline and skew proposed version bumps. Pass the target ref so only tags reachable from that ref are considered via git tag --merged. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tools/feature_version_audit.py`:
- Around line 382-384: The code now computes prior_ver using version_ref but the
later “new ini added” / new-feature logic should use the PR-scoped baseline
(base_ref); add pr_prior_ver = get_prior_version(ini_path, base_ref) if ini_path
else None and update the new-feature / "prior_ver is None" checks to reference
pr_prior_ver, while retaining prior_ver (computed with version_ref) for
release-scoped bump proposals; ensure you only call get_prior_version when
ini_path is truthy and replace any uses of prior_ver that detect PR-new
ini/features with pr_prior_ver.
- Around line 403-423: The release-scoped bump logic currently only considers
commits from version_ref..HEAD_REF when building release_changes/all_commits
(see release_changes, all_commits, get_changed_files, get_commits_for_file),
which misses commits merged into the target branch after the PR branch point;
update the logic to include commits from both version_ref..base_ref and
base_ref..HEAD_REF when computing release_changes and all_commits (or, if PR
mode detected, read new_ver from base_ref instead of HEAD_REF) so proposed_ver
reflects the merged outcome and avoids false bump failures.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c45b12f7-2bac-4414-a49e-b0d477a565cb
📒 Files selected for processing (1)
tools/feature_version_audit.py
Two issues introduced by the release-tag baseline change: 1. New-feature detection used `prior_ver is None` to mean "not present in this PR's base", but prior_ver now comes from the release tag. Features added earlier in the release cycle have no release-tag version so every subsequent PR touching them was falsely reported as adding a new feature. Fix: derive pr_prior_ver from base_ref and use it for new-feature / new-ini checks. 2. For non-rebased PRs, commits merged to the target branch after the PR branched are absent from version_ref..HEAD_REF, so proposed_ver can be lower than what base_ref already has. This causes a false "needs bump" when the merged result would inherit the higher version from base. Fix: compare proposed_ver against max(new_ver, pr_prior_ver) to reflect the merged outcome. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
♻️ Duplicate comments (1)
tools/feature_version_audit.py (1)
450-463:⚠️ Potential issue | 🟡 MinorKeep the "new feature" and "new ini" paths mutually exclusive.
A brand-new feature with an ini still matches both branches here, so
notegets overwritten from"New feature..."to"New ini added..."and the feature is appended twice. The first branch also ignorespr_prior_ver, so it can still reclassify an existing base-ref feature when the PR only adds files.💡 Suggested change
- if changes and all(s == "A" for s, _ in changes): + if pr_prior_ver is None and changes and all(s == "A" for s, _ in changes): if ini_path: note = f"New feature (with ini v{new_ver_str})" new_features.append((feature_dir.name, new_ver_str, bump_commit)) is_attention = True else: note = "New feature (missing ini!)" new_features.append((feature_dir.name, "-", bump_commit)) is_attention = True @@ - if ini_path and pr_prior_ver is None and new_ver is not None: + elif ini_path and pr_prior_ver is None and new_ver is not None: note = f"New ini added (v{new_ver_str})" new_features.append((feature_dir.name, new_ver_str, bump_commit)) is_attention = True🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tools/feature_version_audit.py` around lines 450 - 463, The code can classify the same feature twice because the "new feature" block and the "new ini" block both run; update the conditional logic so they are mutually exclusive — for example make the second check an elif or add a guard that the feature wasn't already marked as new (check the same condition used to add to new_features or a local flag). Ensure you reference and preserve variables new_ver/new_ver_str, ini_path, pr_prior_ver, changes, new_features, bump_commit and feature_dir.name so you only append once and only set note to "New ini added..." when the feature wasn't already classified as a new feature and pr_prior_ver logic applies.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@tools/feature_version_audit.py`:
- Around line 450-463: The code can classify the same feature twice because the
"new feature" block and the "new ini" block both run; update the conditional
logic so they are mutually exclusive — for example make the second check an elif
or add a guard that the feature wasn't already marked as new (check the same
condition used to add to new_features or a local flag). Ensure you reference and
preserve variables new_ver/new_ver_str, ini_path, pr_prior_ver, changes,
new_features, bump_commit and feature_dir.name so you only append once and only
set note to "New ini added..." when the feature wasn't already classified as a
new feature and pr_prior_ver logic applies.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ef3cba0c-2f59-4935-91fa-600709c12707
📒 Files selected for processing (1)
tools/feature_version_audit.py
The feature version audit compared against the PR base SHA (tip of dev), so each PR between releases proposed an additional bump on top of whatever dev already had, accumulating spurious version increments.
Fix: in --pr-check mode, anchor prior_ver and commit gathering to the last semver release tag so a bump already applied by an earlier PR in the same release cycle satisfies the check.
Retroactively reset all feature .ini versions to their v1.4.11 baseline and re-ran --apply-bumps to produce correct single-bump values for every feature with functional changes since release.
Also add
* text=auto eol=lfto .gitattributes to enforce LF at the git index level, complementing the existing pre-commit hook.Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com
Summary by CodeRabbit