Just looked into Travis - this bump of protobuf makes our MSRV go up as well - as it uses maybe_uninit that isn't available on 1.33.

What should we do? On the one hand, I haven't gone through protobuf's changelog to see if there are any pressing features we need from this new version, on the other hand, not sure what the advantage of maintaining a MSRV is either.

FWIW #456 also requires a bump to 1.40 MSRV, but it's behind a feature flag.

Assuming librespot would e.g. migrate to tokio 0.2 / futures 0.3 sooner or later I think would mean 1.39 MSRV. Nevertheless I assume it would be good in general to specify for the project what the criteria are for staying on a certain version. E.g. I could imagine something like the project wants to support AVR or some particular architectures, which then would require a certain MSRV.

1.33 is 13 versions behind. I think bumping the MSRV up should be fine. I do usually try to stick with the version that Ubuntu LTS ships with (which is, as of now), Rust 1.41.0 in xenial (16.04).

In any case, you guys should add a rust-toolchain file and pin the MSRV down there so people don't compile against the wrong version.

Please merge this soon so spotifyd can update to a newer librespot version. Thanks !

@ashthespy Thanks !

@ashthespy Thanks for merging! Any chance that you guys release a new version on crates.io? The current installation is sadly broken.

@sirwindfield That would be up to either @awiouy or @sashahilton00 - I don't touch master, moreover they have the permissions for crates.io..

FWIW, the dev branch was building fine post 6ee2dba by pinning to an old version of protobuf - couldn't spotifyd in the meantime use a git dependency, I think there have been a few changes since the last release..

Don't worry, we're not in a hurry. Ye, I could probably create a dev branch and use the git dependency there. I wanted to stick in master to released versions. Thanks though for merging!