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.
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.