🐛 Add support for build metadata precedence in bundle version comparison by joelanford · Pull Request #2273 · operator-framework/operator-controller

pedjak

pedjak

pedjak

pedjak

grokspawn

joelanford

Copilot AI review requested due to automatic review settings

October 23, 2025 18:04

camilamacedo86

camilamacedo86

This change fixes an issue to ensure that operator-controller properly
handles and compares registry+v1 bundle versions that include build
metadata as specified in the semver version.

The intention is that we only treat build metadata as a release value
for registry+v1 bundles, which already have this precedent set. If/when
operator-controller gains support for new bundle types, the intention is
to avoid continuing the practice (and semver violation) of treating
version build metadata as comparable/orderable.

Key changes:
- Introduce VersionRelease type combining semver version with release metadata
- Update bundle comparison logic to consider build metadata when present
- Add exact version matching for pinned versions with build metadata
- Replace GetVersion with GetVersionAndRelease across the codebase
- Ensure successors are determined based on exact version+release matching

This is particularly important for registry+v1 bundles that encode
release information in the build metadata field of their version strings.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
…rove VersionRelease parsing

This commit reverts the user-facing semantic changes to the ClusterExtension
version field that were introduced to support exact version pinning with build
metadata. The version field now ignores build metadata when matching versions,
consistent with semver specification.

Additionally, this commit modifies the VersionRelease parsing logic to be more
tolerant of semver versions whose build metadata is not a valid release. When
build metadata cannot be parsed as a release, the full version (including build
metadata) is preserved in the Version field, with an empty Release field.

Changes include:
- Removed documentation about pinning to exact versions with build metadata
- Removed exactVersionMatcher logic that enforced build metadata equality
- Updated NewLegacyRegistryV1VersionRelease to tolerate non-release build metadata
- Updated test expectations to reflect new behavior

@openshift-ci openshift-ci bot added the approved

Indicates a PR has been approved by an approver from all required OWNERS files.

label

Dec 9, 2025

Copilot AI review requested due to automatic review settings

December 9, 2025 16:10

@joelanford

- Add documentation for AsLegacyRegistryV1Version method explaining
  the build metadata conversion logic
- Fix AsLegacyRegistryV1Version to preserve original build metadata
  when Release field is not set
- Add comprehensive test coverage for NewLegacyRegistryV1VersionRelease
  including edge cases for build metadata and release parsing
- Add test coverage for AsLegacyRegistryV1Version conversion logic
- Improve compare_test.go test structure with descriptive test names
  and assertion functions for better clarity
- Add test case for non-release build metadata comparison

grokspawn added a commit to grokspawn/operator-controller that referenced this pull request

Mar 12, 2026

@grokspawn