@huon I agree that we don’t want to go too far in the opposite direction, in no way am I proposing moving towards stability for libsyntax. One thing that breaks the vicious cycle is that some changes which are pretty minor can just not happen at all (or until we stop exposing libsyntax to tools/plugins). The cost is some cruftiness in exchange for some stability - I believe that is a price worth paying. The other mitigating factor is that large breaking changes are often not much more effort to deal with for plugin authors than small changes, but have much higher benefit for compiler devs. That means changes are more likely to be accepted as they get larger.
@burntsushi Agreed! I’ve been trying to encourage this, I would like other reviewers to do so too.
@llogiq I would like to do this, it is a good idea. However, it is something we haven’t done before and would require quite a bit of coordination and I’m not sure how it would work with testing infrastructure, etc. The cost in peoples’ time to set this up might be prohibitive.
@sfackler my experience is that the cumulative cost can be quite high due to dependencies - there’s a lot of upgrading, a lot of head scratching, etc. even in projects that only indirectly depend on libsyntax. This might be acceptable for dedicated plugin authors, but is friction for downstream users and complicates stuff like Servo’s Rustup or maintaining projects for benchmarking. The frequency of the breakage is also an issue - if these only broke once per cycle it would be better than once every week or so (in fact, maybe we should have an unstable but slow moving branch, I imagine this won’t be popular though).
