Support x86_64-pc-windows-gnu target

[Thomasdezeeuw]

This updates windows-sys to current master and adds the x86_64-pc-windows-gnu target.

/cc @eiderdaus

Closes #1632

[Thomasdezeeuw]

Ah, windows-sys also increased their MSRV beyond 1.46... That's the second dependency that did so (log being the other).

[eiderdaus]

windows-sys 1.52.0 was finally released two weeks ago so I think this can be merged (after rebasing and replacing the patched windows-sys with the new release of course). I found no issues testing this locally. Meanwhile Tokio's MSRV is 1.63 while windows-sys' is 1.56, so after merging this I think it should also be no problem to make a new mio release and use it in Tokio.

[Thomasdezeeuw]

windows-sys 1.52.0 was finally released two weeks ago so I think this can be merged (after rebasing and replacing the patched windows-sys with the new release of course). I found no issues testing this locally. Meanwhile Tokio's MSRV is 1.63 while windows-sys' is 1.56, so after merging this I think it should also be no problem to make a new mio release and use it in Tokio.

Except for Tokio TLS, which has a lower MSRV :( see #1725.

It's an annoying problem I know.

[eiderdaus]

Not sure I understand. Do you propose to wait until Tokio 1.25 is phased out? Why not integrate this change, create a new (seemingly unnecessarily breaking) mio release 0.9 (or even 1.0, why not) and then you can still make bug fix releases for mio 0.8 to support Tokio 1.25. Just like Tokio is handling LTS itself, kind of.

[Thomasdezeeuw]

Not sure I understand. Do you propose to wait until Tokio 1.25 is phased out? Why not integrate this change, create a new (seemingly unnecessarily breaking) mio release 0.9 (or even 1.0, why not) and then you can still make bug fix releases for mio 0.8 to support Tokio 1.25. Just like Tokio is handling LTS itself, kind of.

I'm not going to bump Mio's version for MSRV, that's not a scalable solution.

[Thomasdezeeuw]

We can either wait until March for the TLS version to not be supported any more, or we can decide the TLS version requires a fixed Mio version. We haven't really decided yet.

[eiderdaus]

Not sure I understand. Do you propose to wait until Tokio 1.25 is phased out? Why not integrate this change, create a new (seemingly unnecessarily breaking) mio release 0.9 (or even 1.0, why not) and then you can still make bug fix releases for mio 0.8 to support Tokio 1.25. Just like Tokio is handling LTS itself, kind of.

I'm not going to bump Mio's version for MSRV, that's not a scalable solution.

Well at least it is a solution :-)

We can either wait until March for the TLS version to not be supported any more, or we can decide the TLS version requires a fixed Mio version. We haven't really decided yet.

I'm not sure what you mean by "fixed" in this context. While both Tokio 1.25.x and 1.32.x are "fixed" to mio 0.8.x this does not need to be the case for Tokio master. If mio versions currently in use in Tokio LTS should be updateable in a backwards compatible manner, mio's 1. or 2. version component can still be bumped for backwards incompatible changes. Then the 3. component can be used for bugfixes. It's only a bit unfortunate that mio is still < 1.0 because cargo also sees 0.8.9 -> 0.9.0 as a major change but oh well.

I just find it weird to have mio's development locked on a MSRV that is so much lower than tokio's own master branch MSRV. Certainly there must be some solution. Waiting is none.

[Thomasdezeeuw]

I'm not sure what you mean by "fixed" in this context.

I'm mean Tokio LTS could use a fixed version of Mio v0.8.9, as is fixed to v0.8.9 specifically (not v0.8.x).

I just find it weird to have mio's development locked on a MSRV that is so much lower than tokio's own master branch MSRV. Certainly there must be some solution. Waiting is none.

That's the price of LTS software...

[eiderdaus]

I'm mean Tokio LTS could use a fixed version of Mio v0.8.9, as is fixed to v0.8.9 specifically (not v0.8.x).

But if you bump Mio only to 0.8.10 for further development (including MSRV change etc.), a potential bug in Mio 0.8.9 then can not be fixed in this Tokio LTS version, or? This does not make any sense to me.

That's the price of LTS software...

No. I pointed out a reasonable solution yet you decide to ignore it. That's the price of open source software...

The existence of LTS versions in Tokio does not prevent further development of mio, it's only you. Just edit that Cargo.toml, set version = "0.9.0" and move on.

[Thomasdezeeuw]

I'm mean Tokio LTS could use a fixed version of Mio v0.8.9, as is fixed to v0.8.9 specifically (not v0.8.x).

But if you bump Mio only to 0.8.10 for further development (including MSRV change etc.), a potential bug in Mio 0.8.9 then can not be fixed in this Tokio LTS version, or? This does not make any sense to me.

That's the price of LTS software...

No. I pointed out a reasonable solution yet you decide to ignore it. That's the price of open source software...

Bump Mio to v0.9 also has a cost. It means all users must update and the versions are incompatible with one another.

Also the price of open source software is that is show some respect, which this conversation is starting to lose.

The existence of LTS versions in Tokio does not prevent further development of mio, it's only you. Just edit that Cargo.toml, set version = "0.9.0" and move on.

This is really written by someone who hasn't maintained a library used by multiple people. It can be quite hard for people to update, so "edit that Cargo.toml, set version = "0.9.0" and move on" can't be done by everyone.