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.
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.
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.
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.
> 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.
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.
I'm trying to remember/piece together what happened.
I believe I added a dependency that wouldn't compile with the snapshot I was running (10JUL2015?). So then I updated to a new snapshot (14AUG2015?), and a previous dependency would no longer compile (since it hadn't been updated). I think this could have been due to libc changes, which I guess were marked unstable (and this was the result of them being removed from the main rustc distribution?). I did some manual tweaking, and/or the problem fixed itself in a few days.
I next came back to rust a few months later, where after that experience, I went ahead and updated to the 1.4 release. I figured libraries should generally aim to keep working with numbered releases, regardless of the upgrade treadmill. I guess (in your framework) that's applying unstable expectations to numbered releases, which is what I've been doing this whole thread - I don't care that code will break at future point, but I do desire consistency in the meantime!
I was next surprised to find out that the syntax extensions for eg serde were used completely differently with the numbered releases because procedural macros were disabled (I hadn't yet touched my own projects that use procedural macros or libcore).
The snapshot story is probably better these days, given that libraries should be more stable. It has always been annoying feeling like my rust is continually "out of date" and dependencies could break and require me to update, involuntarily breaking my code. This has been a problem all along, and I had hoped it was over with numbered releases. Alas.
From my perspective the main source of pain is that rust eschews having traditional numbered unstable releases. Instead creating a harsh dichotomy between uber-stable releases and uber-changing snapshots. One can alleviate some of that pain only if they're willing to take the web 2.0 give-up-control-of-your-computing plunge and run eg rustup.sh, which of course helps the fundamental problem to persist. Granted, the problem will be moot as rust libraries become more stable and the stable distribution becomes more featureful. We're apparently just not there yet for my purposes.
Cuil, a downvote for detailing my perspective? I only bring up this meta issue because it's another symptom of the same problem.
If one is onboard with the butt model of constant updates, then of course my problem looks odd and self-imposed. But such assertions that one's own perspective is universal is a source of many of the world's problems.
> 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.
No, I think the point is to just have a specific unstable that corresponds to a specific stable as closely as possibly, and designated as such., Conceivably crates that needed unstable features, but not bleeding edge, could require at least that unstable release, while others that really need bleeding edge features could use nightly. The issue here is that your release procedure treats unstable features differently than everything else, making any crate or code that wants to use any unstable feature resort to using a nightly of some sort. Admittedly, I can see reasons why this might be by design.
You might have good reasons why you think that won't work or be useful (I can think of a few, such as not wanting to promote people building on a specific implementation of an unstable feature). At a minimum, it is at least slightly more work to make sure this new item is released, depending on the release process.
P.S. The prevailing wisdom so far when wanting to use unstable features from a point release is to use a nightly form the same day, but the release policy seems to indicate that the nightly from that time is actually two release versions ahead of the stable that was released the same day:
> This process happens in parallel. So every six weeks, on the same day, nightly goes to beta, beta goes to stable. When 1.x is released, at the same time, 1.(x + 1)-beta is released, and the nightly becomes the first version of 1.(x + 2)-nightly.[1]
I'm a bit unclear on what the best thing to do would be if I wanted to use features from something that is as close as possible to a particular stable release.
