-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
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
Librespot upgrade to 0.4 #1182
Librespot upgrade to 0.4 #1182
Conversation
This seems to be blocking on rust 1.63. Tomorrow, a new rust version will release, so maybe we could up our required version? (if you have a MSRV policy of 5 stable releases back) |
Oh, cool! I only had a quick look and am surprised that the amount of changes is not as big as I feared (given the major version jump 0.2 → 0.4).
I don't think, we have a strict MSRV policy. The closest to such a thing is probably #1123 (comment). I think, bumping to 1.63 or 1.64 should be totally fine. You'll just need to change that in |
I know! Hopefully, once v0.5 lands, the upgrade will be easier.
Nice, I'll just do that. The 1.62 recommendation came from a long time ago, so I think it's OK to bump two versions (12 weeks). |
Just to weigh in on the MSRV discussion: my suggestion of using Gentoo Stable as a heuristic would currently put us at Rust 1.66.1; of course, if we don't actively have a reason to go beyond a specific version, keeping to an older version is fine. So, I'm ok with us bumping to 1.64 for this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes made look good to me, and the checks are passing.
@Icelk, could you address the merge conflicts? They're from the "none" audio controller commit, I believe.
W/r/t the normalization or credentials features, I'd be interested to see what those would look like in practice. For credentials specifically it's interesting to imagine some of our codebase downsizing, but naturally we'd want to ensure we aren't losing functionality.
Yes, I just did :)
Once this is merged, I can try removing our credentials logic and share the process. The cache format / persistence doesn't need to be defined? Because we get the password and username on startup, so the cache is only for speed? Why don't we just keep it in memory? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you again for working on this! I added some comments, but overall this looks good.
I noticed that |
Another thing I could look into in the future :) |
0709ec3
to
5f8b383
Compare
Thanks for the feedback! Everything you mentioned is fixed, and I rebased. |
5f8b383
to
c76f964
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
c76f964
to
f0293a8
Compare
f0293a8
to
f53deb9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, merging! 🚀
Awesome, thanks! |
Upgrades librespot to 0.4
Considerations