[GH-ISSUE #1005] 0.4.0 uses outdated dependencies

kerem commented

2026-02-27 19:30:53 +03:00

Owner

Originally created by @gdesmott on GitHub (May 23, 2022).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1005

Originally assigned to: @roderickvd on GitHub.

Looks like the latest release uses outdated deps. It would be nice to update those so projects using librespot don't end up with duplicates of those crates.

$ cargo outdated -R
Name        Project  Compat  Latest  Kind    Platform
----        -------  ------  ------  ----    --------
env_logger  0.8.4    ---     0.9.0   Normal  ---
rpassword   5.0.1    ---     6.0.1   Normal  ---
sha-1       0.9.8    ---     0.10.0  Normal  ---

Originally created by @gdesmott on GitHub (May 23, 2022). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1005 Originally assigned to: @roderickvd on GitHub. Looks like the latest release uses outdated deps. It would be nice to update those so projects using librespot don't end up with duplicates of those crates. ``` $ cargo outdated -R Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- env_logger 0.8.4 --- 0.9.0 Normal --- rpassword 5.0.1 --- 6.0.1 Normal --- sha-1 0.9.8 --- 0.10.0 Normal --- ```

kerem

2026-02-27 19:30:53 +03:00

closed this issue
added the
help wanted

compilation

dependencies
labels

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@sdroege commented on GitHub (May 23, 2022):

If you run it for the whole workspace you'll get even more

librespot
================
Name        Project  Compat  Latest  Kind    Platform
----        -------  ------  ------  ----    --------
env_logger  0.8.4    ---     0.9.0   Normal  ---
rpassword   5.0.1    ---     6.0.1   Normal  ---
sha-1       0.9.8    ---     0.10.0  Normal  ---

librespot-audio
================
Name     Project  Compat  Latest   Kind    Platform
----     -------  ------  ------   ----    --------
aes-ctr  0.6.0    ---     0.99.99  Normal  ---

librespot-core
================
Name            Project  Compat  Latest  Kind         Platform
----            -------  ------  ------  ----         --------
aes             0.6.0    ---     0.8.1   Normal       ---
env_logger      0.8.4    ---     0.9.0   Development  ---
hmac            0.11.0   ---     0.12.1  Normal       ---
pbkdf2          0.8.0    ---     0.11.0  Normal       ---
priority-queue  1.2.1    ---     1.2.2   Normal       ---
protobuf        2.27.1   ---     3.0.2   Normal       ---
sha-1           0.9.8    ---     0.10.0  Normal       ---
tokio-util      0.6.10   ---     0.7.2   Normal       ---
uuid            0.8.2    ---     1.0.0   Normal       ---
vergen          3.2.0    ---     7.1.0   Build        ---

librespot-protocol
================
Name      Project  Compat  Latest  Kind    Platform
----      -------  ------  ------  ----    --------
protobuf  2.27.1   ---     3.0.2   Normal  ---

librespot-connect
================
Name      Project  Compat  Latest  Kind    Platform
----      -------  ------  ------  ----    --------
protobuf  2.27.1   ---     3.0.2   Normal  ---

librespot-discovery
================
Name           Project  Compat  Latest   Kind         Platform
----           -------  ------  ------   ----         --------
aes-ctr        0.6.0    ---     0.99.99  Normal       ---
hmac           0.11.0   ---     0.12.1   Normal       ---
sha-1          0.9.8    ---     0.10.0   Normal       ---
simple_logger  1.16.0   ---     2.1.0    Development  ---

librespot-playback
================
Name             Project  Compat  Latest   Kind    Platform
----             -------  ------  ------   ----    --------
alsa             0.5.0    ---     0.6.0    Normal  ---
cpal             0.13.4   ---     0.13.5   Normal  ---
glib             0.10.3   ---     0.15.11  Normal  ---
gstreamer        0.17.4   ---     0.18.8   Normal  ---
gstreamer-app    0.17.2   ---     0.18.7   Normal  ---
gstreamer-audio  0.17.2   ---     0.18.7   Normal  ---
jack             0.7.3    ---     0.10.0   Normal  ---
parking_lot      0.11.2   ---     0.12.0   Normal  ---
rodio            0.14.0   ---     0.15.0   Normal  ---
sdl2             0.34.5   ---     0.35.2   Normal  ---
zerocopy         0.3.0    ---     0.6.1    Normal  ---

librespot-metadata
================
Name      Project  Compat  Latest  Kind    Platform
----      -------  ------  ------  ----    --------
protobuf  2.27.1   ---     3.0.2   Normal  ---

@sdroege commented on GitHub (May 23, 2022): If you run it for the whole workspace you'll get even more ``` librespot ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- env_logger 0.8.4 --- 0.9.0 Normal --- rpassword 5.0.1 --- 6.0.1 Normal --- sha-1 0.9.8 --- 0.10.0 Normal --- librespot-audio ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- aes-ctr 0.6.0 --- 0.99.99 Normal --- librespot-core ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- aes 0.6.0 --- 0.8.1 Normal --- env_logger 0.8.4 --- 0.9.0 Development --- hmac 0.11.0 --- 0.12.1 Normal --- pbkdf2 0.8.0 --- 0.11.0 Normal --- priority-queue 1.2.1 --- 1.2.2 Normal --- protobuf 2.27.1 --- 3.0.2 Normal --- sha-1 0.9.8 --- 0.10.0 Normal --- tokio-util 0.6.10 --- 0.7.2 Normal --- uuid 0.8.2 --- 1.0.0 Normal --- vergen 3.2.0 --- 7.1.0 Build --- librespot-protocol ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- protobuf 2.27.1 --- 3.0.2 Normal --- librespot-connect ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- protobuf 2.27.1 --- 3.0.2 Normal --- librespot-discovery ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- aes-ctr 0.6.0 --- 0.99.99 Normal --- hmac 0.11.0 --- 0.12.1 Normal --- sha-1 0.9.8 --- 0.10.0 Normal --- simple_logger 1.16.0 --- 2.1.0 Development --- librespot-playback ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- alsa 0.5.0 --- 0.6.0 Normal --- cpal 0.13.4 --- 0.13.5 Normal --- glib 0.10.3 --- 0.15.11 Normal --- gstreamer 0.17.4 --- 0.18.8 Normal --- gstreamer-app 0.17.2 --- 0.18.7 Normal --- gstreamer-audio 0.17.2 --- 0.18.7 Normal --- jack 0.7.3 --- 0.10.0 Normal --- parking_lot 0.11.2 --- 0.12.0 Normal --- rodio 0.14.0 --- 0.15.0 Normal --- sdl2 0.34.5 --- 0.35.2 Normal --- zerocopy 0.3.0 --- 0.6.1 Normal --- librespot-metadata ================ Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- protobuf 2.27.1 --- 3.0.2 Normal --- ```

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

Thanks for putting this in. To give some direction to this discussion, I would like to split two things:

a burning issue we have right now with an outdated cpal dependency
the general state of dependencies

w.r.t. no. 1 I could really use the help to find out why the current librespot 0.4.0 crate pulls in cpal-0.12 and thereby causes the build to fail. Please see the Gitter chat for some initial findings. I would like to sort this out as soon as possible. It looks like we have to yank 0.4.0 and release a 0.4.1 to fix this.

w.r.t. no. 2, yes it would be nice if we were on the latest patch releases. The list above may be misleading because it also presents the delta to the latest major releases. Many major releases are API-incompatible or even require a higher MSRV. So for librespot 0.4.x we should be on the latest 0.1.x versions of dependencies and not always on the latest 0.x.y.

In new-api we are on a higher MSRV and have already upgraded a lot of dependencies. This branch represents new developments If you want to take inventory of legacy dependencies, then please use that branch as reference and submit PRs to upgrade any if so necessary.

For now please focus on issue no. 1: why is the crate build failing because of pulling in cpal 0.12?

@roderickvd commented on GitHub (May 23, 2022): Thanks for putting this in. To give some direction to this discussion, I would like to split two things: 1) a burning issue we have right now with an outdated cpal dependency 2) the general state of dependencies w.r.t. no. 1 I could really use the help to find out why the current librespot 0.4.0 crate pulls in `cpal-0.12` and thereby causes the build to fail. Please see the Gitter chat for some initial findings. I would like to sort this out as soon as possible. It looks like we have to yank 0.4.0 and release a 0.4.1 to fix this. w.r.t. no. 2, yes it would be nice if we were on the latest patch releases. The list above may be misleading because it also presents the delta to the latest major releases. Many major releases are API-incompatible or even require a higher MSRV. So for `librespot` 0.4.x we should be on the latest `0.1.x` versions of dependencies and not always on the latest `0.x.y`. In `new-api` we are on a higher MSRV and have already upgraded a lot of dependencies. This branch represents new developments If you want to take inventory of legacy dependencies, then please use that branch as reference and submit PRs to upgrade any if so necessary. For now please focus on issue no. 1: why is the crate build failing because of pulling in `cpal` 0.12?

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@akoww commented on GitHub (May 23, 2022):

Hi. Today I had the same problem building the current version 0.4 of librespot.
I'm not really deep into this topic but the following thing I could find out:

librespot-playback has some dependencies and cpal is one of them.

cpal = { version = "<0.13.5", optional = true }

This line forced cargo to use the 0.12 version of cpal within the playback-project which lead to multiple versions within the whole project.

I don't know if it helps anyone, but using version = "0.13.4" helped me compiling project in the current state

@akoww commented on GitHub (May 23, 2022): Hi. Today I had the same problem building the current version 0.4 of librespot. I'm not really deep into this topic but the following thing I could find out: librespot-playback has some dependencies and cpal is one of them. > cpal = { version = "<0.13.5", optional = true } This line forced cargo to use the 0.12 version of cpal within the playback-project which lead to multiple versions within the whole project. I don't know if it helps anyone, but using version = "0.13.4" helped me compiling project in the current state

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

Many major releases are API-incompatible or even require a higher MSRV.

protobuf, hmac, aes-ctr, and vergen are the major ones I found so far as far as API-incompatibles. Pretty much everything else can be solved by bumping the MSRV to the latest Rust stable version. We already know each other's opinion on bumping the MSRV...

@JasonLG1979 commented on GitHub (May 23, 2022): > Many major releases are API-incompatible or even require a higher MSRV. `protobuf`, `hmac`, `aes-ctr`, and `vergen` are the major ones I found so far as far as API-incompatibles. Pretty much everything else can be solved by bumping the MSRV to the latest Rust stable version. We already know each other's opinion on bumping the MSRV...

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

Those four have already been solved in new-api so no problems there.

@roderickvd commented on GitHub (May 23, 2022): Those four have already been solved in `new-api` so no problems there.

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

I don't know if it helps anyone, but using version = "0.13.4" helped me compiling project in the current state

Can anyone confirm this? This might just be the solution if I misunderstood the Cargo dependency resolver.

@roderickvd commented on GitHub (May 23, 2022): > I don't know if it helps anyone, but using version = "0.13.4" helped me compiling project in the current state Can anyone confirm this? This might just be the solution if I misunderstood the Cargo dependency resolver.

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

That MSRV is really holding us back?

@JasonLG1979 commented on GitHub (May 23, 2022): That MSRV is really holding us back?

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

Can anyone confirm this? This might just be the solution if I misunderstood the Cargo dependency resolver.

No go if the MSRV stays at 1.53. = "0.13.4" pulls in alsa 0.6 which requires =< 1.56.

@JasonLG1979 commented on GitHub (May 23, 2022): > Can anyone confirm this? This might just be the solution if I misunderstood the Cargo dependency resolver. No go if the MSRV stays at 1.53. = "0.13.4" pulls in alsa 0.6 which requires =< 1.56.

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

Bumping gstreamer is also a no go as it depends on 2021. We're stuck on 1.53 in our CI.

@JasonLG1979 commented on GitHub (May 23, 2022): Bumping gstreamer is also a no go as it depends on 2021. We're stuck on 1.53 in our CI.

kerem commented

2026-02-27 19:30:53 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

A lot of the others were pretty simple.

@JasonLG1979 commented on GitHub (May 23, 2022): A lot of the others were pretty simple.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

https://github.com/librespot-org/librespot/pull/1006

@JasonLG1979 commented on GitHub (May 23, 2022): https://github.com/librespot-org/librespot/pull/1006

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@sdroege commented on GitHub (May 23, 2022):

OOC, why didn't you update the MSRV to 1.60 or something else more recent with the 0.4 release? Without any ecosystem-wide agreement about MSRVs you're just making your life more difficult.

@sdroege commented on GitHub (May 23, 2022): OOC, why didn't you update the MSRV to 1.60 or something else more recent with the 0.4 release? Without any ecosystem-wide agreement about MSRVs you're just making your life more difficult.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

OOC, why didn't you update the MSRV to 1.60 or something else more recent with the 0.4 release? Without any ecosystem-wide agreement about MSRVs you're just making your life more difficult.

I'm right there with you. IMHO everything should be updated to the most current stable releases if possible baring any major refactoring due to API changes.

@JasonLG1979 commented on GitHub (May 23, 2022): > OOC, why didn't you update the MSRV to 1.60 or something else more recent with the 0.4 release? Without any ecosystem-wide agreement about MSRVs you're just making your life more difficult. I'm right there with you. IMHO everything should be updated to the most current stable releases if possible baring any major refactoring due to API changes.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

OOC, why didn't you update the MSRV to 1.60 or something else more recent with the 0.4 release? Without any ecosystem-wide agreement about MSRVs you're just making your life more difficult.

Oh but there is. Keeping an as low as feasibly possible MSRV provides the greatest backward compatibility. Looking at the top 10 downloaded crates on crates.io, rand is on 1.36, syn, quote and proc-macro2 on 1.31, libc and verde on 1.13, unicode-xid on 1.17 and autocfg on 1.0.

I repeatedly feel like I have to "defend" this position when I'm just trying to be a good Rustacean here. On the contrary I have always shown to be open to good arguments, but I don't consider upgrading because we can to be one. This is exactly what alsa did and see where that got us: this dependency hell! We should not infect other projects with constraints that could be avoided entirely.

I find these discussions discouraging and hope we can all focus on fixing the issue at hand.

Closing off I also repeat that I'm open to changing the MSRV policy with and only with majority support from contributors and maintainers alike. I'm trying to run a democratic community here on the basis of good engineering arguments, not anyone's personal beliefs including my own. Going round in circles costs all of us time we can much better spend on other things.

@roderickvd commented on GitHub (May 23, 2022): > OOC, why didn't you update the MSRV to 1.60 or something else more recent with the 0.4 release? Without any ecosystem-wide agreement about MSRVs you're just making your life more difficult. Oh but there is. Keeping an as low as feasibly possible MSRV provides the greatest backward compatibility. Looking at the top 10 downloaded crates on crates.io, `rand` is on 1.36, `syn`, `quote` and `proc-macro2` on 1.31, `libc` and `verde` on 1.13, `unicode-xid` on 1.17 and `autocfg` on 1.0. I repeatedly feel like I have to "defend" this position when I'm just trying to be a good Rustacean here. On the contrary I have always shown to be open to good arguments, but I don't consider upgrading because we can to be one. This is exactly what `alsa` did and see where that got us: this dependency hell! We should not infect other projects with constraints that could be avoided entirely. I find these discussions discouraging and hope we can all focus on fixing the issue at hand. Closing off I also repeat that I'm open to changing the MSRV policy with and only with majority support from contributors and maintainers alike. I'm trying to run a democratic community here on the basis of good engineering arguments, not anyone's personal beliefs including my own. Going round in circles costs all of us time we can *much* better spend on other things.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

How many regular contributors are there really? It's basically just you and me on the regular and others drop in from time to time?

@JasonLG1979 commented on GitHub (May 23, 2022): How many regular contributors are there really? It's basically just you and me on the regular and others drop in from time to time?

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

Those crates are also MUCH lower level than librespot.

@JasonLG1979 commented on GitHub (May 23, 2022): Those crates are also MUCH lower level than librespot.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

I understand your desire to be conservative but tech marches on. There are older versions of librespot people can use if they don't want the "latest and greatest". New stable releases should themselves depend of the most current stable deps at the time of there release. That's just how that goes. That's how you minimize dup deps and dep Hell situations.

@JasonLG1979 commented on GitHub (May 23, 2022): I understand your desire to be conservative but tech marches on. There are older versions of librespot people can use if they don't want the "latest and greatest". New stable releases should themselves depend of the most current stable deps at the time of there release. That's just how that goes. That's how you minimize dup deps and dep Hell situations.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

How many regular contributors are there really? It's basically just you and me on the regular and others drop in from time to time?

I highly value the opinion of @sashahilton00 (the owner of this repo really) and @kingosticks.

Those crates are also MUCH lower level than librespot.

It takes nothing away from the point that breaking compatibility while gaining nothing in the way of functionality or security is a stupid thing to do. A low as feasible MSRV is a desirable trait, bumping when something more desirable functionality comes on our way.

I understand your desire to be conservative but tech marches on. There are older versions of librespot people can use if they don't want the "latest and greatest". New stable releases should themselves depend of the most current stable deps at the time of there release. That's just how that goes. That's how you minimize dup deps and dep Hell situations.

I like to lead by example. MSRV upgrades should be treated as a SemVer breaking change. Projects can choose to follow a certain major branch and all would be good.

@roderickvd commented on GitHub (May 23, 2022): > How many regular contributors are there really? It's basically just you and me on the regular and others drop in from time to time? I highly value the opinion of @sashahilton00 (the owner of this repo really) and @kingosticks. > Those crates are also MUCH lower level than librespot. It takes nothing away from the point that breaking compatibility while gaining *nothing* in the way of functionality or security is a stupid thing to do. A low as feasible MSRV is a desirable trait, bumping when something more desirable functionality comes on our way. > I understand your desire to be conservative but tech marches on. There are older versions of librespot people can use if they don't want the "latest and greatest". New stable releases should themselves depend of the most current stable deps at the time of there release. That's just how that goes. That's how you minimize dup deps and dep Hell situations. I like to lead by example. MSRV upgrades should be treated as a SemVer breaking change. Projects can choose to follow a certain major branch and all would be good.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

Leading by example also means staying the most up to date so that it forces other projects to do the same so that things don't stagnate.

@JasonLG1979 commented on GitHub (May 23, 2022): Leading by example also means staying the most up to date so that it forces other projects to do the same so that things don't stagnate.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@sdroege commented on GitHub (May 23, 2022):

MSRV upgrades should be treated as a SemVer breaking change.

Yeah I fully agree with that, but then 0.4 was a breaking version update from 0.3. In any case, your call and I understand your desire to be as conservative as possible. Personally I gave up on staying far behind whenever I do a breaking version update, mostly because a) very few crates in the ecosystem seem to care so you always have to stay behind with dependencies too (and miss out on improvements) and be very careful with updating and still things will regularly break, b) there are useful new features in newer Rust versions that make my life as a maintainer easier, c) updating the Rust toolchain is trivial thanks to really great release management (almost no regressions ever) and rustup. It seems mostly problematic for Linux distros in my experience (Debian maintainer here), but IMHO the version of the toolchain they ship is for building the software they ship and not for development purposes on that distro.

Anyway, your call! Sorry for bringing this up, it seems to be a sensitive topic here :)

My main reason for reporting the outdated versions is that a project I'm maintaining is pulling in multiple versions of various crates because of this and that's not a great situation either.

@sdroege commented on GitHub (May 23, 2022): > MSRV upgrades should be treated as a SemVer breaking change. Yeah I fully agree with that, but then 0.4 was a breaking version update from 0.3. In any case, your call and I understand your desire to be as conservative as possible. Personally I gave up on staying far behind whenever I do a breaking version update, mostly because a) very few crates in the ecosystem seem to care so you always have to stay behind with dependencies too (and miss out on improvements) and be very careful with updating and still things will regularly break, b) there are useful new features in newer Rust versions that make *my* life as a maintainer easier, c) updating the Rust toolchain is trivial thanks to really great release management (almost no regressions ever) and rustup. It seems mostly problematic for Linux distros in my experience (Debian maintainer here), but IMHO the version of the toolchain they ship is for building the software they ship and not for development purposes on that distro. Anyway, your call! Sorry for bringing this up, it seems to be a sensitive topic here :) My main reason for reporting the outdated versions is that a project I'm maintaining is pulling in multiple versions of various crates because of this and that's not a great situation either.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

@sdroege

How does this look?:

Name                          Project  Compat  Latest   Kind    Platform
----                          -------  ------  ------   ----    --------
librespot-audio->aes-ctr      0.6.0    ---     0.99.99  Normal  ---
librespot-connect->protobuf   2.27.1   ---     3.0.2    Normal  ---
librespot-core->aes           0.6.0    ---     0.8.1    Normal  ---
librespot-core->hmac          0.11.0   ---     0.12.1   Normal  ---
librespot-core->pbkdf2        0.8.0    ---     0.11.0   Normal  ---
librespot-core->protobuf      2.27.1   ---     3.0.2    Normal  ---
librespot-core->sha-1         0.9.8    ---     0.10.0   Normal  ---
librespot-core->vergen        3.2.0    ---     7.1.0    Build   ---
librespot-discovery->aes-ctr  0.6.0    ---     0.99.99  Normal  ---
librespot-discovery->hmac     0.11.0   ---     0.12.1   Normal  ---
librespot-discovery->sha-1    0.9.8    ---     0.10.0   Normal  ---
librespot-metadata->protobuf  2.27.1   ---     3.0.2    Normal  ---
librespot-protocol->protobuf  2.27.1   ---     3.0.2    Normal  ---
sha-1                         0.9.8    ---     0.10.0   Normal  ---
sha-1->block-buffer           0.9.0    ---     Removed  Normal  ---
sha-1->digest                 0.9.0    ---     0.10.3   Normal  ---
sha-1->opaque-debug           0.3.0    ---     Removed  Normal  ---

That's after https://github.com/librespot-org/librespot/pull/1007

@JasonLG1979 commented on GitHub (May 23, 2022): @sdroege How does this look?: ``` Name Project Compat Latest Kind Platform ---- ------- ------ ------ ---- -------- librespot-audio->aes-ctr 0.6.0 --- 0.99.99 Normal --- librespot-connect->protobuf 2.27.1 --- 3.0.2 Normal --- librespot-core->aes 0.6.0 --- 0.8.1 Normal --- librespot-core->hmac 0.11.0 --- 0.12.1 Normal --- librespot-core->pbkdf2 0.8.0 --- 0.11.0 Normal --- librespot-core->protobuf 2.27.1 --- 3.0.2 Normal --- librespot-core->sha-1 0.9.8 --- 0.10.0 Normal --- librespot-core->vergen 3.2.0 --- 7.1.0 Build --- librespot-discovery->aes-ctr 0.6.0 --- 0.99.99 Normal --- librespot-discovery->hmac 0.11.0 --- 0.12.1 Normal --- librespot-discovery->sha-1 0.9.8 --- 0.10.0 Normal --- librespot-metadata->protobuf 2.27.1 --- 3.0.2 Normal --- librespot-protocol->protobuf 2.27.1 --- 3.0.2 Normal --- sha-1 0.9.8 --- 0.10.0 Normal --- sha-1->block-buffer 0.9.0 --- Removed Normal --- sha-1->digest 0.9.0 --- 0.10.3 Normal --- sha-1->opaque-debug 0.3.0 --- Removed Normal --- ``` That's after https://github.com/librespot-org/librespot/pull/1007

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

👍 and all those have been updated in new-api already. They might lag a patch release or two behind there but the major upgrades have been done.

@roderickvd commented on GitHub (May 23, 2022): :+1: and all those have been updated in `new-api` already. They might lag a patch release or two behind there but the major upgrades have been done.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

For a 0.4.2 I can backport everything else at some point (after 0.4.1 gets a little mileage) if you like since we're no longer held back by the MSRV?

@JasonLG1979 commented on GitHub (May 23, 2022): For a 0.4.2 I can backport everything else at some point (after 0.4.1 gets a little mileage) if you like since we're no longer held back by the MSRV?

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@roderickvd commented on GitHub (May 23, 2022):

Honestly I would much rather promote new-api to dev, wrinkle out a few bugs with the HTTP backend and release 0.5. We've got something pretty good and usable in there already! Then target the major effort for dealer web socket stuff for 0.6.

@roderickvd commented on GitHub (May 23, 2022): Honestly I would much rather promote `new-api` to `dev`, wrinkle out a few bugs with the HTTP backend and release 0.5. We've got something pretty good and usable in there already! Then target the major effort for `dealer` web socket stuff for 0.6.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 23, 2022):

Fair enough.

@JasonLG1979 commented on GitHub (May 23, 2022): Fair enough.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@sashahilton00 commented on GitHub (May 24, 2022):

I haven't had much time recently to look at what's happened in the new api branch or indeed to give it a test, but given that it is the future of where this repo is going I'd echo Roderick's view of moving to it sooner rather than later, and thus concentrating developments efforts there - there's already several commits that are going to have to be reviewed and merged in from dev, it would be good to minimise divergence.

Additionally, we should probably expend some effort on documenting the protocol so that others can implement a client in their language of choice - as demonstrated by the recent activity around libspotify, there are still people looking for a solution to that use case, and interest in having a librespot-esque client in whatever language they're using - it doesn't look like Spotify is planning on releasing an alternative official solution anytime soon.

@sashahilton00 commented on GitHub (May 24, 2022): I haven't had much time recently to look at what's happened in the new api branch or indeed to give it a test, but given that it is the future of where this repo is going I'd echo Roderick's view of moving to it sooner rather than later, and thus concentrating developments efforts there - there's already several commits that are going to have to be reviewed and merged in from dev, it would be good to minimise divergence. Additionally, we should probably expend some effort on documenting the protocol so that others can implement a client in their language of choice - as demonstrated by the recent activity around libspotify, there are still people looking for a solution to that use case, and interest in having a librespot-esque client in whatever language they're using - it doesn't look like Spotify is planning on releasing an alternative official solution anytime soon.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@sdroege commented on GitHub (May 24, 2022):

How does this look?:

That leaves

block-buffer / digest / sha-1 at version 0.9 (0.10 is latest)

All other duplicates for my case are gone now.

@sdroege commented on GitHub (May 24, 2022): > How does this look?: That leaves - `block-buffer` / `digest` / `sha-1` at version 0.9 (0.10 is latest) All other duplicates for my case are gone now.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 24, 2022):

Most of the divergence issues were caused because changes from dev were merged into the new branch instead of the new branch being rebased on dev to get the changes. That's what caused what we have here where a branch appears to be several commits behind and ahead of dev. Not only that but it makes a mess of the commit history.

@JasonLG1979 commented on GitHub (May 24, 2022): Most of the divergence issues were caused because changes from dev were merged into the new branch instead of the new branch being rebased on dev to get the changes. That's what caused what we have here where a branch appears to be several commits behind and ahead of dev. Not only that but it makes a mess of the commit history.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 24, 2022):

IMHO that should be cleaned up before it's merged into dev and from now on we should never do that again. We should always rebase.

@JasonLG1979 commented on GitHub (May 24, 2022): IMHO that should be cleaned up before it's merged into dev and from now on we should never do that again. We should always rebase.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 24, 2022):

How does this look?:

That leaves

block-buffer / digest / sha-1 at version 0.9 (0.10 is latest)

All other duplicates for my case are gone now.

There was one place that the latest version of sha1 was a drop in replacement and another where it would have required refactoring so I just left it so at least librespot as a whole would not have a dup.

@JasonLG1979 commented on GitHub (May 24, 2022): > > How does this look?: > > That leaves > > * `block-buffer` / `digest` / `sha-1` at version 0.9 (0.10 is latest) > > All other duplicates for my case are gone now. There was one place that the latest version of sha1 was a drop in replacement and another where it would have required refactoring so I just left it so at least librespot as a whole would not have a dup.

kerem commented

2026-02-27 19:30:54 +03:00

Author

Owner

@roderickvd commented on GitHub (May 26, 2022):

This is fixed with #1004 for 0.4.0. Like I said before, those remaining few crates have been updated in new-api.

@roderickvd commented on GitHub (May 26, 2022): This is fixed with #1004 for 0.4.0. Like I said before, those remaining few crates have been updated in `new-api`.

kerem referenced this issue

2026-02-27 20:00:34 +03:00

[PR #479] [MERGED] Bump libmdns to 0.2.6 (fixes #478) #947

Rows
Columns

[GH-ISSUE #1005] 0.4.0 uses outdated dependencies #479