If there’s going to be any project focusing on backwards-compatible, incremental advancement of SuperCollider, it will require that (1) we can break a given piece of SC while leaving other pieces unchanged, (2) we can support several versions of SOME pieces where there is demand (and people to maintain them), and (3) we can provide reasonable paths to update user code to newer versions. This is not “SC3” nor is it “SC4” - it’s “SC4, SC5, SC6…SC99” - no flashy all-at-once redesign, just incremental forward progress that walks the line between tender and ruthless.
I proposed iterating Quarks into a proper versioned module system that would support the kind of piecemeal breaking changes I’m thinking of. I would consider this a hard requirement for making breaking changes, if we want to avoid simply forking development and the community in ways that are gonna be very disruptive. I would be very happy to turn this into a more concrete and detailed formal roadmap, if it would be helpful to organize work on this.
IMO this work (or something equivalent) has to be done before any other “future of SC” conversations can bear fruit - there’s a lot of very clear and straightforward engineering required here, and I’d estimate moving this forward is going to be a 6+ month effort - this is a lot of time to continue discussing exactly how to break apart and push the class library forward. Even when this groundwork is in place, there are some very obvious and non-controversial class lib re-organization tasks (e.g. a separate module for GUI) that will be great starting points to work out the kinks of the “SC-next modularization” workflow. Even the most radical “SC-next” version, full of cool breaking changes, will still need a proper versioned module system else it will run aground of the same problems as we have now.
I’d gently encourage anyone invested in this topic to focus on these immediate engineering challenges, and let the more challenging topics simmer for a while. These near-term projects are interesting and challenging, and have some open questions but are still nonetheless pretty solve-able. They are also achievable with the engineering resources and expertise we have right now - no utopian transformation or huge influx of contributors is needed, just some proposals, pull requests, some polite discussion, and some people writing code to make it work. We will learn a LOT from doing this work - we will probably learn things that will invalidate much of the “future of the class library” conversations we’re having now anyway.