@cwh does other package types have similar concepts as maven SNAPSHOT? If yes, we should allow redeploying of those versions as well.

Addressed the mutable-version concern.

Container images are now treated as mutable because the package version is the image tag, so retagging/pushing a new manifest to the same tag remains allowed. Other package types keep the shared redeploy protection by default. Maven still keeps its special SNAPSHOT behavior in the Maven handler.

Verification:

• git diff --check passed
• mvn -pl server-plugin/server-plugin-pack-container -am compile could not run in this workspace because mvn is not available on PATH; java and javac are also unavailable

Review

The design looks solid. The isVersionMutable() hook on PackSupport gives a clean extension point with immutability-by-default, and the guard in DefaultPackService.createOrUpdate() correctly blocks redeploys that would drop or replace already-referenced blobs for pack types that pass a blob collection.

Correctness

• Non-SNAPSHOT Maven artifact replacement is rejected in MavenPackHandler before metadata is updated; SNAPSHOT versions remain mutable as expected.
• Container images are appropriately treated as mutable, which matches tag-based registry semantics and addresses the earlier discussion about other package types with mutable versions.
• Handlers such as Helm that previously allowed silent replacement of an existing version now inherit protection through the shared service layer.
• The check runs before dao.persist() and compares SHA-256 hashes from existing blob references, which is the right invariant.
• HTTP 409 (SC_CONFLICT) is an appropriate response.

Minor notes (non-blocking)

• Maven keeps a separate enforcement path because it passes null for packBlobs; that split is reasonable given how Maven tracks blobs via MavenData.
• No automated tests were added; the logic is straightforward, but regression tests around redeploy rejection would be a useful follow-up.

Approved.