Replies: 7 comments 31 replies
-
|
These are compelling reasons. (weak) concept ACK from me. |
Beta Was this translation helpful? Give feedback.
-
|
We would also want to decide how to do this -- last time we did a major release for all projects across the rust-bitcoin ecosystem, which I liked because it didn't break any of my projects, though it was a significant amount of work and @Kixunil had an argument that this was actually a bad way to do it. Downstream users who get broken are of course able to use |
Beta Was this translation helpful? Give feedback.
-
|
If we're going to do this then I'd like to take advantage of it in APIs, mainly the |
Beta Was this translation helpful? Give feedback.
-
|
I am in favor of 1.51 which would give us const generics and Array::IntoIter. But we can also do that later and the informal 2-year rule would put 1.51 on Feb end 2023 |
Beta Was this translation helpful? Give feedback.
-
|
I'd prefer to maintain all of these as hard rules:
So currently I'm a nack on 1.51. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Just because its soon-ish anyway, I'd suggest we do this after Debian bookworm releases, which puts the 1.41 people on a then-ancient version of Debian. That should be around 2023-04 or so, depending on how long a few things take. I only suggest this because none of the reasons here seem super pressing to me - I agree they're all nice, but if they wait a few releases it doesn't seem like all that much difference? If y'all think this is pressing I'd be okay with seeing it now-ish. |
Beta Was this translation helpful? Give feedback.
-
|
Since I'd like to take advantage of it in API we at least shouldn't do it after we have 1.0. If it takes some time it's probably OK. Maybe I will try make a demo PR showing how much it'd change if I get some free time.
Wow! I though it'll be around summer. Suddenly Debian releases don't feel slow. :D |
Beta Was this translation helpful? Give feedback.
-
|
Heh, I think it varies - more bugs -> summer, less bugs -> April/May |
Beta Was this translation helpful? Give feedback.
-
|
Even if MSRV bump was the next thing to do after current thing (re-org / crate smashing) it would, in my opinion, not happen till March - the crate smashing PRs take ages to merge because they all conflict plus there is going to be an epic amount of discussion required to work out what goes where. We've only just scratched the surface and its been going on for a while already. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, if we decide today to bump MSRV the release will be out much later. I don't expect that crazy changes as the last time because we're jumping versions with fewer language changes. I'd personally mostly focus on array APIs and do the rest later. |
Beta Was this translation helpful? Give feedback.
-
|
Another possibility: bump to 1.48 ~now and to 1.51 somewhat soon after bookworm release. 1.51 contains much more const generics features. Maybe we could even change the |
Beta Was this translation helpful? Give feedback.
-
|
Why should Rust be the same as other languages though? Different language, different culture... 🤷♂️ (Although I do find it amusing that people supposedly concerned with security don't understand the value of signed packages...) |
Beta Was this translation helpful? Give feedback.
-
|
Because there's good reason things were done the way they are in other languages, and the mess of npm should have showed us that that specific culture results in way more pain and suffering than it adds value. The rust community should learn from the mistakes of others, not repeat them because they're new and shiny. |
Beta Was this translation helpful? Give feedback.
-
Please, be specific, there are many languages with many different good and bad ideas and some of the "good reasons" may not apply to Rust.
Again, please be specific. NPM is a mess but from my POV Rust solves almost all of its problems (signing is the missing part). |
Beta Was this translation helpful? Give feedback.
-
I spent 5 or 10 minutes playing with crev the other day. I think if we got into a habit of using this I'd be much more comfortable with dependencies and Rust's behavior. We could maybe have an in-repo script that users can run which pin our dependencies to only ones that have been vetted, or highlight ones that haven't. I also learned about a tool Without crev my perception of cargo is that it's only "better than NPM" because the sanity waterline is higher in Rust-land than in JS-land, not because there's any inherent improvement to the problems of malicious crates, giant unvettable dependency trees, and automatic updates. I'll open a new discussion with these notes. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, we need |
Beta Was this translation helpful? Give feedback.
-
|
So are we willing and able to bump MSRV to 1.48.0 directly after 0.30.0 is released and do a quick 0.31.0? (I did re-read the whole thread but its Friday afternoon and I didn't really get a clear idea of where we stand). |
Beta Was this translation helpful? Give feedback.
-
|
Didn't re-read but that's exactly what I remember. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think we need to do a quick 0.31.0. On reflection I think the "do a release just to bump MSRV" process serves no real purpose -- if people want to have a release in which they only bump their compiler version but make no other changes, they can use literally any release prior to the MSRV bump. But yes, let's bump to 1.48.0 immediately after 0.30.0 is released. |
Beta Was this translation helpful? Give feedback.
-
|
I think "quick" meant to also do related changes? |
Beta Was this translation helpful? Give feedback.
-
|
I think we can get those changes out at their own pace. Though we can certainly prioritize them if they make our lives easier. |
Beta Was this translation helpful? Give feedback.
-
|
Done in #1729 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'd like to propose bumping MSRV again to 1.48. This version is 2 years old now and is available in Debian stable. (Interestingly Buster, containing 1.41 is now EOL) I believe the benefits of this are significant mainly thanks to a bunch of
coretraits being implemented on all arrays. We have several arrays above 32 items and so could remove a bunch of manual trait impls and improve APIs. E.g. we could requireHash::Inner: AsRef<[u8]>which would improve generic processing of hashes (see #1321 (comment)), I think we could have a betterToHextrait.Other things I find interesting:
constsupport#[track_caller]- we wouldn't have to conditionally enable it as I suggested.no_stdbecomes the same removing a bunch of complexity in docs and maybe also CIAlternatively, 1.47 provides most (maybe all) of the desired benefits and is already MSRV for
no_std. I find 1.48 more practical but if anyone needs 1.47 I'm OK with that.Beta Was this translation helpful? Give feedback.
All reactions