Using this online semver checker: https://jubianchi.github.io/semver-check/
Notice how
version "3.4.5" is compatible with expression "3."
but...
version "3.4.5-1" is NOT compatible with expression "3."
How can I change my compatibility expression to include this pre-release version?
That's because pre-release versions are not included by default.
According to the docs:
SemVer comparisons without a pre-release comparator will skip pre-release versions. For example, >=1.2.3 will skip pre-releases when looking at a list of releases while >=1.2.3-0 will evaluate and find pre-releases.
In order to match that pre-release version, you could use, for example: ~3 >3.4.5-0.
3.4.5-1 satisfies constraint ~3 >3.4.5-0
Related
What is the smallest version base on Semantic Versioning 2.0.0?
Semantic Versioning 2.0.0: https://semver.org/
https://go.dev/ref/mod go mod force me to use Semantic Versioning 2.0.0 as git tag. And I need to make sure my version is increase. I just commit my library first time, so I think I should use the smallest version as first version.
Base on my test the smallest version is v0.0.0-0 . No biggest version when string length is unlimited.
Here is my test base on some example:
https://gist.github.com/bronze1man/90aad9f41692c16895be3e499021dc73
valid (sort by smallest to biggest)
v0.0.0-0
v0.0.0-0+0
v0.0.0-2
v0.0.0-12
v0.0.0--0
v0.0.0-12alpha
v0.0.0-alpha
v0.0.0-alpha12
v0.0.0+0
v0.0.0
v0.0
v0
v0.0.1-0
v0.0.1-0.0
v0.0.1-0.0.0.0.0.0.0.0.0.1
v0.0.1-0.0.0.1
v0.0.1-0.0.1
v0.0.1-0.1
v0.0.1-1
v0.0.1-a
v0.0.1-alpha
v0.0.1
v0.0.2
v0.0.12
v1.0.0-0
v1
v1.0
v1.0.0
v2.0.0
v12.0.0
v99999999999999999999999999999999.0.0
invalid
v0.0.0.1
v0.0.0-000
v0.0.0-002
v0.0.0+
v0.0.0-
v0-0
v1-0
Which of these package version numbers is canonical for NPM?
2.0.0-pre1
2.0.0-pre.1
NPM just uses the semver package, which follows https://semver.org/, so there isn't any "npm-flavored" semver.
According to semver, both of your examples are valid prerelease versions; the only requirement is that the version number is followed by a hyphen and a series of dot-separated alphanumeric identifiers.
That said, in my opinion, the second is more idiomatic, assuming that you are trying to convey the idea of prerelease version "pre #1". 2.0.0-beta.37, makes it clear that this is beta #37, which comes after prelease beta #36 and before prelease beta #38; as opposed to 2.0.0-beta37, which is ambiguous: beta37 could mean beta #37, or it could be a codename for this particular prerelease, followed by 2.0.0-blue42 etc. etc.
I want to carefully release a new version of a crate to give users a chance to test it first. How can I release it to crates.io as a "beta"? (similar to how npm has #next tagged releases).
It's not supposed to be a breaking change, so I'm not going to increase semver-major version. I don't want it to be automatically picked when users do cargo upgrade until the beta testing period ends.
What version syntax should I use for the release?
Do I need to use any special cargo options when releasing it?
How do users use cargo/Cargo.toml to opt in into the beta version?
Semantic versioning defines the concept of a pre-release version:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
To use this in Cargo, publish a crate of the planned version number but append a pre-release identifier. I suggest -beta.0, allowing you to easily increase if you need a second:
[package]
name = "library"
version = "0.1.1-beta.0"
To use this, you need to specifically opt into it by putting beta into the version requirement:
[dependencies]
library = "0.1.1-beta"
To test this, I:
Spun up a local crates.io server
Uploaded the crate library with version 0.1.0
Used library = "0.1.0" in a binary project app — it resolved to 0.1.0
Uploaded the crate library with version 0.1.1-beta.0
Ran cargo update in app — the version did not change.
Changed to library = "0.1.1-beta" in app, ran cargo update — the version did change.
Uploaded the crate library with version 0.1.1-beta.1
Ran cargo update in app — the version did change.
New to Nodejs and looking at the dependencies section of the package.json file. Could someone explain to me what the ~ and * symbols do when setting the versions?
From the documentation:
The following range styles are supported:
1.2.3 A specific version. When nothing else will do. Note that build metadata is still ignored, so 1.2.3+build2012 will satisfy this range.
>1.2.3 Greater than a specific version.
<1.2.3 Less than a specific version. If there is no prerelease tag on the version range, then no prerelease version will be allowed either, even though these are technically "less than".
>=1.2.3 Greater than or equal to. Note that prerelease versions are NOT equal to their "normal" equivalents, so 1.2.3-beta will not satisfy this range, but 2.3.0-beta will.
<=1.2.3 Less than or equal to. In this case, prerelease versions ARE allowed, so 1.2.3-beta would satisfy.
1.2.3 - 2.3.4 := >=1.2.3 <=2.3.4
~1.2.3 := >=1.2.3-0 <1.3.0-0 "Reasonably close to 1.2.3". When using tilde operators, prerelease versions are supported as well, but a prerelease of the next significant digit will NOT be satisfactory, so 1.3.0-beta will not satisfy ~1.2.3.
~1.2 := >=1.2.0-0 <1.3.0-0 "Any version starting with 1.2"
1.2.x := >=1.2.0-0 <1.3.0-0"Any version starting with 1.2"
~1 := >=1.0.0-0 <2.0.0-0 "Any version starting with 1"
1.x := >=1.0.0-0 <2.0.0-0 "Any version starting with 1"
Ranges can be joined with either a space (which implies "and") or a || (which implies "or").
Addendum:
* means any version.
According to MSDN, there is version attribute but if you specify a wrong version number VC still compiles the code. For example:
// MSO.DLL (Microsoft Office, Object Library)
// Office 10.0 => version(2.2)
// Office 11.0 => version(2.3)
// Office 12.0 => version(2.4)
#import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52" version(123.456) //< wrong version.
How to force the compiler to fail on such code? I would like to use only specific version of type-library.
You can't. The rules are explained in LoadRegTypeLib:
LoadRegTypeLib compares the requested version numbers against those
found in the system registry, and takes one of the following actions:
If one of the registered libraries exactly matches both the
requested major and minor version numbers, then that type library is
loaded.
If one or more registered type libraries exactly match the
requested major version number, and has a greater minor version number
than that requested, the one with the greatest minor version number is
loaded.
If none of the registered type libraries exactly match the
requested major version number (or if none of those that do exactly
match the major version number also have a minor version number
greater than or equal to the requested minor version number), then
LoadRegTypeLib returns an error.
Your case matches the 2nd bullet, not the 3rd. Microsoft does spend a lot of effort on making these type libraries backward compatible. Not taking advantage of it is easy to do. Build your project on a machine with the right type library. Copy the generated .tlh and .tli files to your project directory and check them in. Replace the #import with #includes for those files.