Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add broader support for semver constraints #307

Open
cjnosal opened this issue Nov 29, 2021 · 2 comments · May be fixed by #342
Open

add broader support for semver constraints #307

cjnosal opened this issue Nov 29, 2021 · 2 comments · May be fixed by #342
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@cjnosal
Copy link

cjnosal commented Nov 29, 2021

The current readme notes that semver only supports alpha/beta/rc prereleases, and that variants are either ignored or must be an exact match.

There are images that don't fall in these constraints, but are still valid semver. For example:
1.2.3-variant-revision1
1.2.3-variant-revision2

I would like to be able to watch for the latest revision of variant.

More generally, I do not want restrictions on what valid semver tags can be used.

The readme links to mastermind as the underlying semver lib, which does handle these patterns:

package main

import (
	"fmt"

	"github.com/Masterminds/semver"
)

func main() {
	version1 := "1.2.3-variant-rev1"
	version2 := "1.2.3-variant-rev2"

	c, err := semver.NewConstraint(">= 1.2.3-0")
	if err != nil {
		fmt.Println("bad constraint")
	}

	v1, err := semver.NewVersion(version1)
	if err != nil {
		fmt.Println("bad version")
	}
	v2, err := semver.NewVersion(version2)
	if err != nil {
		fmt.Println("bad version")
	}

	a := c.Check(v1)
	fmt.Println(a)

	comp := v1.LessThan(v2)
	fmt.Println(comp)
}
@cjnosal cjnosal mentioned this issue Nov 29, 2021
Open
@xtremerui xtremerui added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers labels Apr 13, 2022
@xtremerui
Copy link
Contributor

I believe bumping mastermind/semver to latest version should fix the issue.

@cjnosal
Copy link
Author

cjnosal commented Jun 8, 2023

I've run into this again with the latest 1.8.0.
The tag format I'm trying to consume this time is of the form 1.0.0-build.3-myorg.123456 (an upstream git tag using -build for prereleases, and I'm adding a myorg.$(date +%s) to ensure a unique fixed tag every time the image is rebuilt (e.g. due to a new compiler or base image) where a 1.0.0-build.3 tag would float.

Looking at check.go, this violates two separate constraints of the current resource implementation:

  1. if there's a - in the prerelease the trailing portion must be a static variant
  2. build is not allowed as a pre-release.

These constraints don't appear to required by Semver 2.0, but I couldn't find docs on whether those patterns are codified by an OCI spec or convention?

I would like to generalize the prerelease checks. A few different paths are:

  1. allow any number of - in the prerelease portion of the tag
  2. Variant could maintain the assumption that it comes last for backwards compatibility (otherwise could be generalized to any exact match when splitting on -)
  3. allow the user to opt in to arbitrary pre-release prefixes via a new source field for backwards compatibility (otherwise could remove the allow-list of alpha/beta/rc)

@cjnosal cjnosal linked a pull request Jun 9, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: support arbitrary prerelease strings cjnosal/registry-image-resource
2 participants
@cjnosal @xtremerui