Support run image rebase based on semver tags

[loewenstein]

Right now the spec prohibits an update from e.g. run:1.1 to run:1.2 (unless force: true is used) , with this statement

• Else if <force> is false, the provided MUST be found inrunImage.imageorrunImage.mirrors`

This breaks reproducible builds (and rebases), because it enforces to use a floating tag run image in the builder.toml.

While I can see value in preventing accidental rebases from e.g. ubuntu:22.04 to ubuntu:24.04 based run images, it is a severe limitation for stacks (aka build and run images) that use semver properly and would represent the example as run:1.1 being based on ubuntu:22.04 and then of course going for run:2.0 for an ubuntu:24.04 bump.

See also the discussion on Slack.

[natalieparellano]

@loewenstein this makes sense to me. Could you suggest some alternate language for the spec?

[loewenstein]

I guess it needs a spec and a lifecycle change. If we do not detect semver via heuristic, we could allow builder metadata to indicate semver based tags in run image metadata. WDYT?

[loewenstein]

@natalieparellano where is the file format layed out in https://buildpacks.io/docs/reference/config/builder-config/ actually specified?

[edmorley]

I agree there are times when it's valid to rebase from one tag to another, and that the spec (and lifecycle/pack) implementations should allow for rebasing to different tags in cases where the operator knows they are compatible.

However, I think: (a) this issue is broader than just semver (for example, what if I've renamed my tags, and just need to migrate existing images to the new tag name?), (b) trying to make this work using semver-like heuristics is going to be fragile/not cover all scenarios (for example, semver requires versions like X.Y.Z, but what if people use X.Y versions instead? Or what about other versioning variants?)

Something simpler that would solve both of these, would be to instead add support for overriding the tag/image name checks entirely, and providing a completely new image name/tag to be used as the rebase target (with suitable warnings that it's up to the user/operator to ensure the two images are ABI compatible). For example pack rebase myapp --onto new-image:new-tag

[loewenstein]

Something simpler that would solve both of these, would be to instead add support for overriding the tag/image name checks entirely, and providing a completely new image name/tag to be used as the rebase target (with suitable warnings that it's up to the user/operator to ensure the two images are ABI compatible). For example pack rebase myapp --onto new-image:new-tag

If I am not mistaken, then this is already supported with pack rebase --run-image new-image:new-tag --force and it would also be very inconvenient to require users to know about compatibility, when operators anyway do.

(b) trying to make this work using semver-like heuristics is going to be fragile/not cover all scenarios (for example, semver requires versions like X.Y.Z, but what if people use X.Y versions instead? Or what about other versioning variants?)

With this, I agree, it should be possible for version schemes that express compatibility - independent of the number of digits a versioning scheme has. Would you have something specific in mind besides x.y.z and x.y?

If it is basically those two versions, we might be able to get something like

[[run.images]]
image: run-exact:latest
rebase: exact

[[run.images]]
image: run-semver:1.2.3
rebase: semver

[[run.images]]
image: run-range:1.2
rebase: range
range: <2.0

WDYT?

[loewenstein]

@edmorley do you have a concrete versioning scheme in mind other than semver. If it is widely used it could be added to the proposed rebase property values.

If there is nothing concrete now, I would propose to go with rebase: exact | semver for now - other schemes can easily added when there is concrete demand. WDYT?