I operate git-version with git-flow.
I want to bump version up to 1.0.0 when I merge develop to main.
Version as of develop is 0.1.0, and I did merge it to main with commit message contains bumping keyword.
However it hit the constraint below, and the version didn't increment.
https://gitversion.net/docs/reference/version-increments
One thing to be aware of: If the current version is an alpha-version (i.e. 0.x.y.), attempting to bump the major version will merely bump the minor (eg from 0.2.0 to 0.3.0 instead of 1.0.0). Once the current version is greater than 1.0.0, bumping the major version works as expected.
I think this is very ordinary case, but we have the constraint in some reason. Why do we have it?
How can I bump my version to 1.0.0?
You need to git tag the commit on main, with v1.0.0. This will produce 1.0.0 semver, and also kickstart gitversion's semver calculation like how the documentation shows.
But wait, what? Why? 👇
0.1.0 is the default starting semver gitversion produces on a repository without ANY git tags with accompanying semver, like v1.2.3 and v0.3.2.
Without any git tags, even with commit log message bumps, gitversion will never produce any semver higher than 0.2.0.
The reason is gitversion expects you to use git tags to help initiate subsequent semver calculations.
But even if your repository has git tags like v0.2.0 or even v0.99.999, gitversion will still not produce any semver that breaks the major version barrier from 0 to 1, regardless of commit log message bumps.
The point is, when you have created the v1.0.0 git tag to that commit on main, then gitversion will function as the documentation describes.
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
I have a crate that has several dependencies that use one common dependency, same as the root project. An intersecting range, though.
I.e.,:
[dependencies]
bitcoin="0.28"
hdpath="0.6" <- this one depends on `>=0.27`
hwkey="0.1" <- this one depends on `=0.28`
And the current latest version is bitcoin:0.29.2
The current Cargo.lock file contains bitcoin:0.28.1 so it all works for all of the deps and compiles fine.
But if I try to publish the crate there is no way to enforce it using the version from Cargo.lock and it tries to use two different version of bitcoin. The latest 0.29.2 for hdpath because it allows any version, and 0.28.1 for other parts because they are not compatible with the latest one.
That obviously doesn't work because it produces incompatible data types.
Is there any way to force Cargo to disable such an upgrade and use version from the lock file?
I want to know how to choose the versions of the dependencies used by azure-iot-sdk-c.
for example, I plan to use:
azure-iot-sdk-c from github.com/Azure/azure-iot-sdk-c.git, release_2018_02_09_after_bump_version(3deb0ca3a8e2d220a50175bef71d16d1650a3a79),
then how do I know the right submodule/library versions for it? for example, the sub-modules in https://github.com/Azure/azure-uamqp-c/releases, github.com/Azure/azure-umqtt-c.git ...?
Thanks in advance.
Software and library is managed using the version. And libraries should be designed backwards-compatible when the MAJOR version is same.
A common way to find the suitable version for GitHub project's sub-modules is looking the release date of that project. For example of Azure-iot-sdk-c_release_2018_02_09, the version sub-module of azure-uamqp-c is 1.x.x published before 09/02/2018, so we can use any version of 1.x.x azure-uamqp-c. And of cause, the recommend version should be the latest version of that major version(1.2.3) at present.
More detail about concept of version and sub-modules, you can refer the links below:
Working with submodules
Semantic Versioning 2.0.0
If anyone else lands here after searching the error message of 3deb0ca3a8e2d220a50175bef71d16d1650a3a79;
I found this (https://github.com/Azure/azure-iot-sdk-c/blob/main/doc/master_to_main_rename.md) which refers to azure iot branchn renaming from master -> main on Dec 1st -21, which may explain the trouble finding the reference.
By updating my *.bb file which refers to the github with:
git#linktoyourgit.com ;main
This will reference the specific branch main to find the correct revision.
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.
A few days ago, cross-compiling to JavaScript via Emscripten has finally hit nightly. I wanted to compile a project using glium in that manner. However, there are still many Emscripten-related bugs in many crates. While maintainers usually fix those bugs quickly, they don't necessarily release those bug fixes to crates.io immediately.
In my case, glium depends on glutin. glutin had a bug which is fixed now, but only in the git repository, not on crates.io. Note: glutin is not a direct dependency of my project; only an indirect one through glium!
How do I tell Cargo to use the glutin repository as source for glutin instead of crates.io?
You can use the [replace] section in your project's Cargo.toml. You can find the documentation about that feature here in the Cargo documentation.
In your case, glium depends on glutin 0.6.1. The version 0.6.1 on crates.io still contains the bug. So just add this to your Cargo.toml:
[replace]
"glutin:0.6.1" = { git = 'https://github.com/tomaka/glutin' }
Note however,
[...] that the replaced crate must not only have the same name but also the same version.
But even in the case of a version-mismatch (the repository already contains a newer version), you could still be in luck if the crate's maintainer creates git tags for every version (many in the Rust community do). In that case you can just specify the tag:
[replace]
"glutin:0.6.1" = {
git = 'https://github.com/tomaka/glutin'
tag = 'v0.6.1'
}
Sadly, this won't work with glutin, because the maintainer did not create tags for every version. In that case you can simply find the last commit before the version was bumped and specify it with rev = 'b4a3d0...' or specify a specific branch with the branch = '...' key.