4 ms·

There is a beta release (https://www.rust-lang.org/downloads.html https://www.rust-lang.org/downloads.html), but I don't think it includes unstable features.

mindslight 11y ago
Oh yeah, forgot about that. Different purpose than what I'm talking about though. Perhaps mine would be more appropriately named "1.6 with alpha features".
- dikaiosune 11y ago
  I had the same response when I realized a feature I really wanted was only on nightly (and would probably still be interested). However, in the last month-ish I've been using a fresh nightly every day, multirust has made it super easy to update, and I've only had breaking changes to my dependencies once.
  - mindslight 11y ago
    I only switched to building releases at 1.4 because I thought the nightly treadmill could finally be over. Alas I guess I'll skip installing 1.6 and just switch back to sporadically-updated checkouts whenever some dependency has breaking changes (ooh, such stable). I'm not looking to get the rats on my face and switch to butt-based development ala rustup/multirust/etc.
    - kbenson 11y ago
      > butt-based development Oh, cloud-to-butt, will you ever stop delivering the fun? I hope not.
- Gankro 11y ago
  1.6 with alpha features is essentially the nightly on the day that 1.6 entered beta. Backports are incredibly rare while the trains are running.
  - kbenson 11y ago
    I think the issue here is the difference between "is" and "essentially". Having a guaranteed matched release with alpha features would apparently be useful, for at least one person. Not being guaranteed could cause some real headaches under certain circumstances.
    - pcwalton 11y ago
      What are those circumstances? There are no stability guarantees for unstable features, so I don't see how a nightly build that happens to correspond to a major version has value over any other nightly build. The stability you would get by sticking to "1.6 + features" seems precisely equal to the stability you would get from picking a recent nightly and sticking to that build. It sounds to me like the real issue here is that procedural macros aren't stable, not anything about the release process.
      - mindslight 11y ago
        Stabilizing procedural macros would fix this one issue, but IMHO a different release process would have fix the pain as well. My case specifically: Wanting hard-to-stabilize features like procedural macros and no_std. Using external dependencies that work with stable, but when used with unstable they expect you are updating nightly. Not updating nightly due to a wacky idea that people should control tools and not vice-versa. The first time I open a project in a week is not the time I want it to fail compiling due to language/library changes. Maybe my impression is caused by the previous rapid change of nightlies (renaming in libraries, etc), and using month-old snapshots wouldn't be too bad these days. But still after several major releases I'd hope the stable tarballs would have been suitable for general use. Instead of removing not-yet-stable features, they should be put behind a feature gate. With the idea that anybody who explicitly opts-in to unstable features and then complains when they're not forward-compatible can simply be told to pound sand.
        pcwalton 11y ago
        Stable is suitable for general use. By complaining that when you update nightly you have to update your code that uses unstable features, you are in effect asking us to stabilize everything. Unstable means unstable. > ith the idea that anybody who explicitly opts-in to unstable features and then complains when they're not forward-compatible can simply be told to pound sand. This never works in practice. We'd have too many crates that depended on nightly features. There would be 10x the number of complaints here on HN if we did what you suggested and enabled unstable features on stable. The only option would be to de facto stabilize everything. Again, it really sounds like your complaint is just that procedural macros aren't stable. I'm sorry they've taken longer than you wanted to finish, but we have lots of work on our plate.

mindslight 11y ago

Oh yeah, forgot about that. Different purpose than what I'm talking about though. Perhaps mine would be more appropriately named "1.6 with alpha features".

dikaiosune 11y ago
I had the same response when I realized a feature I really wanted was only on nightly (and would probably still be interested). However, in the last month-ish I've been using a fresh nightly every day, multirust has made it super easy to update, and I've only had breaking changes to my dependencies once.
- mindslight 11y ago
  I only switched to building releases at 1.4 because I thought the nightly treadmill could finally be over. Alas I guess I'll skip installing 1.6 and just switch back to sporadically-updated checkouts whenever some dependency has breaking changes (ooh, such stable). I'm not looking to get the rats on my face and switch to butt-based development ala rustup/multirust/etc.
  - kbenson 11y ago
    > butt-based development Oh, cloud-to-butt, will you ever stop delivering the fun? I hope not.
Gankro 11y ago
1.6 with alpha features is essentially the nightly on the day that 1.6 entered beta. Backports are incredibly rare while the trains are running.
- kbenson 11y ago
  I think the issue here is the difference between "is" and "essentially". Having a guaranteed matched release with alpha features would apparently be useful, for at least one person. Not being guaranteed could cause some real headaches under certain circumstances.
  - pcwalton 11y ago
    What are those circumstances? There are no stability guarantees for unstable features, so I don't see how a nightly build that happens to correspond to a major version has value over any other nightly build. The stability you would get by sticking to "1.6 + features" seems precisely equal to the stability you would get from picking a recent nightly and sticking to that build. It sounds to me like the real issue here is that procedural macros aren't stable, not anything about the release process.
    - mindslight 11y ago
      Stabilizing procedural macros would fix this one issue, but IMHO a different release process would have fix the pain as well. My case specifically: Wanting hard-to-stabilize features like procedural macros and no_std. Using external dependencies that work with stable, but when used with unstable they expect you are updating nightly. Not updating nightly due to a wacky idea that people should control tools and not vice-versa. The first time I open a project in a week is not the time I want it to fail compiling due to language/library changes. Maybe my impression is caused by the previous rapid change of nightlies (renaming in libraries, etc), and using month-old snapshots wouldn't be too bad these days. But still after several major releases I'd hope the stable tarballs would have been suitable for general use. Instead of removing not-yet-stable features, they should be put behind a feature gate. With the idea that anybody who explicitly opts-in to unstable features and then complains when they're not forward-compatible can simply be told to pound sand.
      - pcwalton 11y ago
        Stable is suitable for general use. By complaining that when you update nightly you have to update your code that uses unstable features, you are in effect asking us to stabilize everything. Unstable means unstable. > ith the idea that anybody who explicitly opts-in to unstable features and then complains when they're not forward-compatible can simply be told to pound sand. This never works in practice. We'd have too many crates that depended on nightly features. There would be 10x the number of complaints here on HN if we did what you suggested and enabled unstable features on stable. The only option would be to de facto stabilize everything. Again, it really sounds like your complaint is just that procedural macros aren't stable. I'm sorry they've taken longer than you wanted to finish, but we have lots of work on our plate.