Stabilizing procedural macros would fix this one issue, but IMHO a different release process would have fix the pain as well. My case specifically:<p>Wanting hard-to-stabilize features like procedural macros and no_std.<p>Using external dependencies that work with stable, but when used with unstable they expect you are updating nightly.<p>Not updating <i>nightly</i> 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 <i>not</i> the time I want it to fail compiling due to language&#x2F;library changes.<p>Maybe my impression is caused by the previous rapid change of nightlies (renaming in libraries, etc), and using month-old snapshots wouldn&#x27;t be too bad these days. But still after several major releases I&#x27;d hope the stable tarballs would have been suitable for general use.<p>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&#x27;re not forward-compatible can simply be told to pound sand.