🐛 Add support for build metadata precedence in bundle version comparison by joelanford · Pull Request #2273 · operator-framework/operator-controller
Copilot AI review requested due to automatic review settings
October 23, 2025 18:04This 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
bot
added
the
approved
label
Dec 9, 2025Copilot AI review requested due to automatic review settings
December 9, 2025 16:10- 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, 2026This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters