@xoofx Welcome to life after Unity! Take care, and find some time for a break. And thanks for the work we did together some years back, I learned a lot!

@sschoener but relying on "someone should test this once before release" is not realistic to work if you have hundreds of packages, and you want to make sure that non of them ever regress to break the incremental build (especially if the regression is often not significant in small test project builds).

@sschoener yes, these issues are individually easy to fix. The problem is making sure they don't resurface. IIRC, I tried to add a "repeat build does nothing test" to the package validation suite, but it was complicated for reasons I don't remember :)

@sschoener Yeah, it's too fragile in practice. In retrospect, the biggest regret I have is that we never touched the "data build" part (and some package or custom project code _always_ changes some data between builds on reasonably non-trivial projects). "Data builds" were always "Don't worry about that, someone else already has plans for that" (which was a frequent cause of stuff not being fixed at Unity for very long times).

@sschoener Ugh, so much wrong here. We spent a lot of time, making sure that an empty build does *nothing*. But so easy for packages, etc, to break and regress it. Should have added tests for this to big projects (like MegaCity). If you are interested in digging deeper, opening Library/Bee/fullprofile.json in Chromes tracing viewer should give you a lot of details of what is going on.