Yuki Okushi
Yuki Okushi
> Strictly, yes, but I think we can exercise leeway here -- it only affects a subset of targets, and those targets made the same breaking change at their root....
> You mean there's no policy on supported platforms for the libc crate in particular? Yes, e.g. https://github.com/rust-lang/libc/issues/1412. Since we have a lot of supported env, I guess it's hard...
triage: https://github.com/rust-lang/rust/pull/107129 has been merged and was released as 1.71. Can we set 0.3's MSRV as 1.71 and restart an FCP?
@rust-lang/libs Could we restart FCP or are there any other blockers?
I think this is a breaking change as it changes the interface. I'm, however, fine to accept it as long as they aren't usable at all across all NetBSD versions...
This is a breaking change and I'd recommend deprecating them first to inform users. Read our policy: https://github.com/rust-lang/libc/blob/master/CONTRIBUTING.md#breaking-change-policy
Please do not change their types, also it'd be great if could squash commits into one once it's done!
Yes, we should inform users that we're going to introduce a breaking change before actually doing so. By this users can prepare that change and we can prevent their code...
Sorry for the absence! I am considering adding a Cargo feature to cfg breaking changes so that we no longer have to _misuse_ the deprecation attribute. Give me some time...
Thanks! Could you add the target to rustc first? This crate follows rustc's platform support for adding/removing targets.