rpm version of rust subpackage tools

[Josh Stone]

In rust.spec, we include a few tools that are closely tied to the
compiler, each presented with independent versions in their rpm.

>  # Some sub-packages are versioned independently of the rust compiler
> and runtime itself.
>  # Also beware that if any of these are not changed in a version bump, then the release
>  # number should still increase, not be reset to 1!
>  %global rustc_version 1.31.1
>  %global cargo_version 1.31.0
>  %global rustfmt_version 1.0.0
>  %global rls_version 1.31.7
>  %global clippy_version 0.0.212 
Do folks find that kind of granularity useful?

I suspect that most people really only care about the primary Rust
version. If you're using "rustup" to get the upstream binaries, the
available toolchain versions use the Rust version, and each tool is just
a component therein. You won't see their specific version at all unless
you run them with "--version".

Those tool versions have problems for packaging too. In the current beta
for 1.32, rustfmt and clippy haven't changed, which is why I have that
cautionary note about the release number. Worse, the beta's rls is at
1.31.6 -- seemingly backwards due to a weird way some fixes were applied
for Rust 1.31.1. (It's not actually a regression though.)

So, would anyone mind if I unified the rpm version with just the Rust
version for everything? That would put us at 1.32.0-1 in the next
release, which should be fine as an upgraded NVR all around. The tools
will still report whatever they want for "--version", of course.

[Josh Stone]

On 1/10/19 2:16 PM, Josh Stone wrote:
>  In rust.spec, we include a few tools that are closely tied to the
>  compiler, each presented with independent versions in their rpm.
>  
> > # Some sub-packages are versioned independently of the rust compiler and runtime
> itself.
> > # Also beware that if any of these are not changed in a version bump, then the
> release
> > # number should still increase, not be reset to 1!
> > %global rustc_version 1.31.1
> > %global cargo_version 1.31.0
> > %global rustfmt_version 1.0.0
> > %global rls_version 1.31.7
> > %global clippy_version 0.0.212
>  
>  Do folks find that kind of granularity useful?
>  
>  I suspect that most people really only care about the primary Rust
>  version. If you're using "rustup" to get the upstream binaries, the
>  available toolchain versions use the Rust version, and each tool is just
>  a component therein. You won't see their specific version at all unless
>  you run them with "--version".
>  
>  Those tool versions have problems for packaging too. In the current beta
>  for 1.32, rustfmt and clippy haven't changed, which is why I have that
>  cautionary note about the release number. Worse, the beta's rls is at
>  1.31.6 -- seemingly backwards due to a weird way some fixes were applied
>  for Rust 1.31.1. (It's not actually a regression though.)
>  
>  So, would anyone mind if I unified the rpm version with just the Rust
>  version for everything? That would put us at 1.32.0-1 in the next
>  release, which should be fine as an upgraded NVR all around. The tools
>  will still report whatever they want for "--version", of course. 
Release day is tomorrow -- last chance for objections...

[Tony Arcieri]

I like it, and would agree that the rustc version is what I actually care
about.

I view all of the subcomponents as part of one logical SDK, and certainly
stopped caring about individual version numbers for those tools after they
started working on stable.

On Wed, Jan 16, 2019 at 1:37 PM Josh Stone <jistone(a)redhat.com&gt; wrote:

>  On 1/10/19 2:16 PM, Josh Stone wrote:
>  > In rust.spec, we include a few tools that are closely tied to the
>  > compiler, each presented with independent versions in their rpm.
>  >
>  >> # Some sub-packages are versioned independently of the rust compiler
>  and runtime itself.
>  >> # Also beware that if any of these are not changed in a version bump,
>  then the release
>  >> # number should still increase, not be reset to 1!
>  >> %global rustc_version 1.31.1
>  >> %global cargo_version 1.31.0
>  >> %global rustfmt_version 1.0.0
>  >> %global rls_version 1.31.7
>  >> %global clippy_version 0.0.212
>  >
>  > Do folks find that kind of granularity useful?
>  >
>  > I suspect that most people really only care about the primary Rust
>  > version. If you're using "rustup" to get the upstream binaries, the
>  > available toolchain versions use the Rust version, and each tool is just
>  > a component therein. You won't see their specific version at all unless
>  > you run them with "--version".
>  >
>  > Those tool versions have problems for packaging too. In the current beta
>  > for 1.32, rustfmt and clippy haven't changed, which is why I have that
>  > cautionary note about the release number. Worse, the beta's rls is at
>  > 1.31.6 -- seemingly backwards due to a weird way some fixes were applied
>  > for Rust 1.31.1. (It's not actually a regression though.)
>  >
>  > So, would anyone mind if I unified the rpm version with just the Rust
>  > version for everything? That would put us at 1.32.0-1 in the next
>  > release, which should be fine as an upgraded NVR all around. The tools
>  > will still report whatever they want for "--version", of course.
>
>  Release day is tomorrow -- last chance for objections...
>  _______________________________________________
>  Rust mailing list -- rust(a)lists.fedoraproject.org
>  To unsubscribe send an email to rust-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  

-- 
Tony Arcieri

[Josh Stone]

On 1/16/19 2:29 PM, Tony Arcieri wrote:
>  I like it, and would agree that the rustc version is what I actually
>  care about.
>  
>  I view all of the subcomponents as part of one logical SDK, and
>  certainly stopped caring about individual version numbers for those
>  tools after they started working on stable. 
Thanks for confirming!

[Manish Goregaokar]

(Clippy maintainer here)

In clippy's case the version number is vestigial, any changes there will be purely
cosmetic (we'll likely 1.0 it and leave it at that)

Clippy is meant to be built along with the compiler using the submodule'd version, so
switching versions for a given compiler isn't something we support anyway.

[Josh Stone]

On 1/17/19 5:58 AM, Manish Goregaokar wrote:
>  In clippy's case the version number is vestigial, any changes
> there
>  will be purely cosmetic (we'll likely 1.0 it and leave it at that) 
I figured as much. If you're not planning to match versions with rustc,
then at least 1.0 seems nicer. However, I see it's also still getting
occasionally published on crates.io, currently 0.0.302, so maybe API
semver concerns apply. I guess you could kludge "--version" separate
from the crate version, like cargo does itself.

>  Clippy is meant to be built along with the compiler using the
>  submodule'd version, so switching versions for a given compiler isn't
>  something we support anyway. 
Right -- we do build it this way from the rustc-src tarball, and the
resulting subpackage is tied to the exact NVR of the compiler to match
libraries, e.g. "Requires: rust(x86-64) = 1.31.1-9.fc30".

[Manish Goregaokar]

If you actually try building the one on crates.io, it won't build, the
0.300 series of versions (and the tail end of 0.200) all deliberately fail
to compile and throw an error message.

The crates.io copy purely exists to redirect people to using rustup, since
clippy *used* to be updated with cargo install.

Thanks,
-Manish Goregaokar


On Thu, Jan 17, 2019 at 1:00 PM Josh Stone <jistone(a)redhat.com&gt; wrote:

>  On 1/17/19 5:58 AM, Manish Goregaokar wrote:
>  > In clippy's case the version number is vestigial, any changes there
>  > will be purely cosmetic (we'll likely 1.0 it and leave it at that)
>
>  I figured as much. If you're not planning to match versions with rustc,
>  then at least 1.0 seems nicer. However, I see it's also still getting
>  occasionally published on crates.io, currently 0.0.302, so maybe API
>  semver concerns apply. I guess you could kludge "--version" separate
>  from the crate version, like cargo does itself.
>
>  > Clippy is meant to be built along with the compiler using the
>  > submodule'd version, so switching versions for a given compiler isn't
>  > something we support anyway.
>
>  Right -- we do build it this way from the rustc-src tarball, and the
>  resulting subpackage is tied to the exact NVR of the compiler to match
>  libraries, e.g. "Requires: rust(x86-64) = 1.31.1-9.fc30".
>