Debian-style release branches

A common thing that I talk to other pro’s and new users about it is the trouble of finding a balance between the cutting-edge side of TouchDesigner we all love and cherish about the software, and the stability we will probably need in most day-to-day usages. The current structure of stable + experimental has been around for a while, and it has been working out relatively well for a while now, but I think adopting a cycle similar to Debian would not only weed out the complaints that pros have about bugs in the stable builds, while providing all users with new features quickly, and then also keeping the experimental build to help have coverage in testing without dedicating too many internal resources to QA.

My breakdown would be something like this (although it’s quite flexible).

Edge branch:
This would be similar to the current experimental builds, just renamed. It would have new features as they’re being developed and are ready for community testing or even just general community feedback on implementation of some features. No guarantee of stability, not to be used in production, same as experimental now. This would be a rolling release with no guarantees of backwards or forwards compatibility.

Feature branch:
Every month (or upon decision that a handful of solid features from the edge branch are ready to be used in the real world), then a new feature branch build would be made. This branch would essentially be similar to the current stable branch we have. In that it should be stable enough for production, and if a bug is found in a feature branch build, it’s a priority to have it fixed if it’s a game breaker in someway. This plays the role of community-based QA between Edge and stable, whereas right now a problem with our currentl Stable/experimental system is that if not enough people use experimental, big bugs can slip right into stable and that can be really problematic for pros (the recent text editor not saving bug is a good example of the type of bug that this feature branch would catch and prevent from landing in a stable branch).

Stable branch:
Every 6 months, a new stable build would get released that rolls whatever new in the features branch into a stable branch (maybe there’s a pseudo feature freeze for 1 month on feature branch to make sure nothing is severely broken). Outside of this twice a year update, stable branch would only receive backports for critical bugs found, like memory leaks, crashing caused by ops misbehaving, SDKs update that fix some broken hardware (but even this I might say would be too forward for the stable branch?). This is the kind of branch I think a lot of big corporate clients want to see exists when they’re thinking of building their own internal teams and having them trained up to be TouchDesigner-focused teams.

I understand this would create a 3rd codebase that needs managing, ideally the efforts of stable/experimental currently just become feature/edge, and then the new stable branch would take up less resource since it only needs a new build every 6 months unless there’s some critical fixes needing to be backported to it (but ideally those all get caught in the feature branch!), so it could even be the job of an intern/co-op student or similar. But the benefits could be quite large, in that it would attract corporate clients looking to buy TouchDesigner at scale (with some assurance of stability), while leveraging the community for QA in the feature branch.

I’d say we currently have that in a way - 2019.30k is your edge branch, 2019.10k is your feature branch, and if you want something from the past 6 months that is not changing at all, then 2018.20k is that.

We actively support 2 builds as you know. Official builds very rarely get any new features added unless they are isolated from the code base and we see the great benefit users could reap from having them added. The Laser CHOP is an example of that, adding it in no way affects other CHOPs or stability. The recent bug introduced in text editor was more a fault with our own operations vs our deployment strategy, as we clearly did not follow our own agreed-upon practices for new features in Official branch. That was a mis-calculation on our part, it should not have been added to the public Official branch, we apologize for that mistake and the uncertainty it created.