The PureScript registry restricts how you may write SemVer ranges to only the following operators: >, >=, and == on the left-hand side, and < and <= on the right-hand side. For example:
>=1.0.0 <2.0.0==1.2.3<=2.0.0
The full reasoning is described in #43, but in a nutshell this is done to help package authors specify correct version ranges for packages.
I would like to propose a further restriction: versions must consist only of major, minor, and patch places. In other words, all versions I’ve written so far, but versions containing the following information would not be allowed in the registry:
- Build metadata, in which metadata is included after the
+character, such as0.12.1+20220105(in this case we’re including a build date with the version) - Prerelease identifiers, in which the prerelease version is included after the
-character, such as5.0.0-rc.1.
Note: This restriction only applies to the registry and official package set. You could still freely tag prerelease versions, for example, and depend on them in your code by pointing at the Git tag directly.
Why?
As with the restriction on declaring version ranges, the proposed metadata restriction is meant to simplify reasoning about dependencies by making version ranges crystal clear.
For example, you may wish to depend on Halogen 6 at any version up to Halogen 7:
{ "halogen": ">=6.0.0 <7.0.0" }
Then, Halogen has a release candidate, 7.0.0-rc.1, which includes breaking changes (it’s a major version bump, after all). Suddenly, your version range admits a broken version! In SemVer, prerelease information is considered “less than” a non-prerelease version.
The correct way to write your version range is actually this:
{ "halogen": ">=6.0.0 <7.0.0-0" }
The use of -0 is to indicate you want any version prior to Halogen 7, including prereleases. I predict that in the overwhelming majority of cases this is what is meant by <7.0.0.
Benefits & Costs
The solution I have proposed (to disallow build metadata and prereleases) avoids ordering ambiguity when restricting version ranges, but at the cost of removing potentially useful information. However, that cost is perhaps not so high:
- In a review of historical package sets I did not find usage of build metadata. We have disallowed build metadata so far in the new registry and no packages have run afoul of the restriction.
- In a review of historical package sets I found minimal use of prerelease information – just Halogen 5 and a handful of other package versions that built against Halogen 5.
- If a package has a release candidate, as Halogen 5 did, you can still depend on it in your projects by pointing to a Git tag instead of a registry version. Arguably this should have been done for the Halogen 5 release candidates.
- If, during the registry alpha, we discover that we really ought to include this information after all then it is no trouble to allow (we simply disable the check that bans these versions).
With this in mind I believe we are better off without this metadata. I don’t think the metadata provides enough benefit to justify the ease of specifying incorrect ranges like <7.0.0 when you don’t mean to include prereleases.
Your Thoughts
I would like to hear what folks think about this proposal before we move forward! Please share your thoughts one way or another and the registry working group will use this discussion to help inform a final decision.
- Disallow build metadata and prerelease identifiers (proposal)
- Allow build metadata and prerelease identifiers
0 voters