Skip to content
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

[pull] master from ruuda:master #2

Open
wants to merge 34 commits into
base: master
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Mar 24, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

zonyitoo and others added 5 commits March 24, 2021 13:09
Version 1.34.2 is what Debian Jessie ships at the time of writing.
The lockfile generated by recent versions of Cargo can't be read by Rust
1.34.2, which I am to support. Delete the lockfile and re-generate it
using Rust 1.34.2.
I always forget to commit this before tagging ...
@pull pull bot added ⤵️ pull merge-conflict Resolve conflicts manually labels Mar 25, 2021
daxpedda and others added 23 commits May 13, 2023 13:43
Travis CI has been dead for two years now ... thank you for your service
Travis, you transformed the world of open source for the better.

While at it, also add a job to test Wasm, since that is supported too
now, but there we can't run the tests easily, so skip that.
Fortunately it looks like the newer libc version is compatible with Rust
1.34.2, so there is no need to bump the minimum supported Rust version.
It looks like crates.io no longer shows this information, and lib.rs
doesn't either, so we are no longer forced to have as many colorful
badges as possible to compete for attention. Let's remove it, it's one
less thing to care about during version bumps.
This is one of my few repositories where I didn't have my default
contribution guide yet.
This ensures that updates to e.g. the Cargo lockfile will be written by
the oldest supported version, so we don't accidentally introduce an
incompatibility.
Despite the former working just fine, it has not been updated in a few
years, and Microsoft published the windows-sys crate. The replacement
feels like pointless churn to me, but if the entire ecosystem is really
making the switch, then who am I to be the node in the graph that is
keeping the winapi dependency alive?
The windows-sys crate uses edition 2021, and the first Rust version that
supports that edition is 1.56.0. However, that version can no longer be
obtained by Rustup, we need to use 1.56.1.
I don't want to bump the MSRV in 12 different places.
It may not look pretty, but at least now I can bump my MSRV in *one*
place and have it update everywhere.
We can just always build for the SGX target, no need to restrict to
"check". This crate is trivial so the overhead is negligible.
Compiling the windows-sys package says:

    package `windows-sys v0.59.0` cannot be built because it requires rustc 1.60 or newer, while the currently active rustc version is 1.56.1

Oh well, if we're bumping the MSRV anyway ...
The 3.5 one is causing nodejs deprecation warnings. Because obviously
you need nodejs to check out a Git repository, and you need your users
to bump the number every 6 months despite there having been no
functional changes for the past several years (or even since launch for
my simple case).

Fortunately, this is now generated with RCL so I only have to bump the
number in *one* place instead of having to bump it in 12 places.
I consider it a breaking change because it bumps the MSRV. Also, there
is no point in updating unless you want to get rid of the "winapi" crate
in your dependency tree, but probably for many users this update will do
the opposite: you have the "winapi" dependency anyway, and this now adds
an additional dependency on "windows-sys" that may not have been there
before. So probably it's best to make a conscious decision about this
to bump the version, rather than getting a larger lockfile as an
unwelcome surprise when updating some packages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants