3 ms·

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.

by Gankro 11y ago

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
        > By complaining that when you update nightly you have to update your code that uses unstable features This isn't it. I feel like, when using unstable, that I've had to update packages that would not have needed updating were I using stable (and still would have worked fine). Maybe I just got a bad impression and switched away from nightlies around the time wider-demanded features started to stabilize. > Again, it really sounds like your complaint is just that procedural macros aren't stable. No, this really isn't it. I fully expect that code using unstable features is going to require changes when I update. I think the root of my gripe comes about from intermediate versioning being punted to "just run nightlies", meaning that rather than being able to reference older versions of packages that work with my compiler version, I'm effectively forced to upgrade and create breakage in my code right then. > I'm sorry they've taken longer than you wanted to finish, but we have lots of work on our plate. Please take whatever time is required to get them "right". And thank you in general.
        pcwalton 11y ago
        But a new nightly shouldn't be breaking stable features, only unstable ones. That's why I'm confused as to why upgrading nightly could possibly break packages, aside from changing unstable features, which you shouldn't be using if you want stability.

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.

by 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
      > By complaining that when you update nightly you have to update your code that uses unstable features This isn't it. I feel like, when using unstable, that I've had to update packages that would not have needed updating were I using stable (and still would have worked fine). Maybe I just got a bad impression and switched away from nightlies around the time wider-demanded features started to stabilize. > Again, it really sounds like your complaint is just that procedural macros aren't stable. No, this really isn't it. I fully expect that code using unstable features is going to require changes when I update. I think the root of my gripe comes about from intermediate versioning being punted to "just run nightlies", meaning that rather than being able to reference older versions of packages that work with my compiler version, I'm effectively forced to upgrade and create breakage in my code right then. > I'm sorry they've taken longer than you wanted to finish, but we have lots of work on our plate. Please take whatever time is required to get them "right". And thank you in general.
      - pcwalton 11y ago
        But a new nightly shouldn't be breaking stable features, only unstable ones. That's why I'm confused as to why upgrading nightly could possibly break packages, aside from changing unstable features, which you shouldn't be using if you want stability.