We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
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
It looks like some bundlers are dropping the leading 0. for pre-1.0 versions.
0.
Here it is for a project of mine – the toDEB and toRPM results both say the version is 1.0, while toDockerImage has the correct 0.1.0 version.
toDEB
toRPM
1.0
toDockerImage
0.1.0
$ nix bundle --bundler github:NixOS/bundlers#toDEB $ nix bundle --bundler github:NixOS/bundlers#toDockerImage $ nix bundle --bundler github:NixOS/bundlers#toRPM $ ls *bash-strict-mode* bash-strict-mode-0.1.0.tar.gz deb-single-bash-strict-mode/: . .. bash-strict-mode_1.0_amd64.deb rpm-single-bash-strict-mode/: . .. bash-strict-mode-1.0-1.x86_64.rpm $
The text was updated successfully, but these errors were encountered:
How do I control the versions on the deb and rpm bundlers anyway?
I have a bunch of binaries that get correct versions when the normal wrapped binaries are produced, but rpm and deb just put 1.0: https://github.com/fedimint/fedimint/releases/tag/v0.3.0-rc.2
Sorry, something went wrong.
Ah! That might be the actual problem – not that the leading component is dropped, but that RPMs and DEBs always get 1.0.
No branches or pull requests
It looks like some bundlers are dropping the leading
0.
for pre-1.0 versions.Here it is for a project of mine – the
toDEB
andtoRPM
results both say the version is1.0
, whiletoDockerImage
has the correct0.1.0
version.The text was updated successfully, but these errors were encountered: