Commenting here since it's tangential, and I don't want to derail your issue, but I think we really need to decide as a community what we consider to be the norm for compiler version support. I think we can be more aggressive than other langs, but different crates have diff needs
-
-
Replying to @sgrif
I agree. To be clear though, if it were only about MSRV, I could overlook that, at least for rand. I still like the LTS idea that boats/aturon proposed. It provides a rallying point. Adding MSRV to Cargo.toml in order to improve failure modes is also a good start.
1 reply 0 retweets 7 likes -
Replying to @burntsushi5
LTS RFC is definitely the most compelling solution I've seen so far. I also agree adding this to Cargo.toml would be great, especially if it affected version resolution
2 replies 0 retweets 5 likes -
Replying to @sgrif @burntsushi5
How’d crate maintainers be compensated ($) for maintaining an LTS version that’s no fun, only pain? There’s no plan for that, AFAICT, making the whole LTS idea accidentally anti-maintainer & pro-freeloading, despite good intentions. “Latest stable Rust only” works economically.
2 replies 1 retweet 8 likes -
Replying to @BRIAN_____ @sgrif
I don't work in crypto. I'm happy to have crypto people tell me the policy doesn't work for them. But that doesn't mean it others can't or shouldn't adopt it.
2 replies 0 retweets 0 likes -
I don't like LTS releases for the same reason I didn't like--and fought against--Firefox's ESR (and was ultimately forced to do it). Takes resources from present and future to accommodate people stuck in the past. Codifies bad practices as accepted and encouraged
3 replies 5 retweets 15 likes -
I maintain dozens of crates. I am just not always going to be able to keep all of them up to date with every best practice. Code needs to be able to sit without needing my attention every 6 weeks. This is churn, and ALSO takes resources.
2 replies 0 retweets 2 likes -
Totally! But I would argue that's good churn (keeping up with an improving ecosystem) vs bad churn with LTS (trading off current improvements or adding complexity to accommodate the past). I only maintain one lib of substance (Juniper) and we choose to do stable - 2 releases FWIW
2 replies 0 retweets 1 like -
I don't really agree with that characterization. To me, churn is a negative thing to be mitigated and minimized. Depending on situation and type of crate, the degree of success will vary. To me, the word "churn" doesn't really apply to LTS maintenance.
1 reply 0 retweets 0 likes -
6 week releases are pitched as part of Rust from day 1 so I signed up for that churn to get the benefits. Validating old rust, investigating bug reports on old rust, not using new lang features or gating them to support old rust is churn I didn't sign up for. LTS conscripts me
1 reply 0 retweets 0 likes
Yes. I've acknowledged several times that LTS is extra work. I know because I do it. I don't understand why people keep trying to tell me that over and over. It's probably time to stop the conversation. It's just going in circles.
-
-
Ah, sorry about that. Probably best to take convo to the RFC anyway...Twitter is not good for nuanced discussions! Thank you very much for your Rust libs BTW, I'm a huge fan of your work.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.