You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Validate that the version is a specific version and doesn't look like a semver version range #415
I think I'd be supportive of this if we check nobody has done this in the existing registry data (if they have, we should explore and understand why people have done this / if it's valid etc.).
Easy to remove the restriction later if it does block valid workflows.
I am curious why we would not simply treat these as non-semantic version numbers? The BNF for valid semantic versions is already limited to specific version numbers; range qualifiers such as ^ are defined by package managers (and can vary between package managers). And our documentation already defines how non-semantic versions are handled:
The registry attempts to parse versions as semantic versions for proper ordering. Non-semantic versions are allowed but will be ordered by publication timestamp.
If using ranges is a common mistake, we could perhaps add a warning / confirmation in the CLI. Is it a common mistake though?
I think it makes it likely that clients implementing things like npm packages accidentally install a version range, rather than a specific version. Which makes it harder for subregistries to provide guarantees about specific packages. I think it's very unlikely people really intend to submit a semver version range a lot of the time as an intentional version string - and we could lift this restriction if there's very good reason people are doing this.
I think it makes it likely that clients implementing things like npm packages accidentally install a version range, rather than a specific version. Which makes it harder for subregistries to provide guarantees about specific packages.
My understanding was that this restriction was primarily for the server version (used by the registry itself), similar to the recent restriction on using latest.
With regards to restricting actual package version numbers, I think we should delegate that responsibility to the package managers themselves. For example, npm already enforces restrictions.
I noticed this issue is still open, but it appears to have been implemented in PR #435. The current implementation validates that both server versions AND package versions are not ranges (applying looksLikeVersionRange() to both).
I see there was some discussion about whether package versions should also be restricted or if the restriction should only apply to server versions (as @jonathanhefner suggested). The final implementation chose the stricter approach of validating both.
Since the functionality has been implemented, perhaps this issue can be closed? Or is there still discussion needed about whether package versions should be exempt from this validation?
Activity
domdomegg commentedon Sep 10, 2025
I think I'd be supportive of this if we check nobody has done this in the existing registry data (if they have, we should explore and understand why people have done this / if it's valid etc.).
Easy to remove the restriction later if it does block valid workflows.
jonathanhefner commentedon Sep 11, 2025
I am curious why we would not simply treat these as non-semantic version numbers? The BNF for valid semantic versions is already limited to specific version numbers; range qualifiers such as
^are defined by package managers (and can vary between package managers). And our documentation already defines how non-semantic versions are handled:If using ranges is a common mistake, we could perhaps add a warning / confirmation in the CLI. Is it a common mistake though?
domdomegg commentedon Sep 11, 2025
I think it makes it likely that clients implementing things like npm packages accidentally install a version range, rather than a specific version. Which makes it harder for subregistries to provide guarantees about specific packages. I think it's very unlikely people really intend to submit a semver version range a lot of the time as an intentional version string - and we could lift this restriction if there's very good reason people are doing this.
jonathanhefner commentedon Sep 11, 2025
My understanding was that this restriction was primarily for the server version (used by the registry itself), similar to the recent restriction on using
latest.With regards to restricting actual package version numbers, I think we should delegate that responsibility to the package managers themselves. For example, npm already enforces restrictions.
feat(validators): Validate that Server versions are not ranges (#435)
feat(validators): Validate that Server versions are not ranges (#435)
ossamalafhel commentedon Sep 14, 2025
Hi team,
I noticed this issue is still open, but it appears to have been implemented in PR #435. The current implementation validates that both server versions AND package versions are not ranges (applying looksLikeVersionRange() to both).
I see there was some discussion about whether package versions should also be restricted or if the restriction should only apply to server versions (as @jonathanhefner suggested). The final implementation chose the stricter approach of validating both.
Since the functionality has been implemented, perhaps this issue can be closed? Or is there still discussion needed about whether package versions should be exempt from this validation?
Thanks!
rdimitrov commentedon Sep 15, 2025
@ossamalafhel - You're right we can close this one, thank you! 💯