commits to proton-master must be visible to everyone so users will test them and bugs will be found before rolling it into steam
No Risks, It's all good things
The reason I haven't been doing this is because the release cycle is actually very short. There isn't a long-lived next
branch where changes are stacked up over weeks. We have a number of developers working on various things in between Proton releases. When we have enough new work to be interesting, I pull all of that work into the next
branch and begin the release cycle. The time between pulling that work into next
and pushing the release public is usually 2-5 days. Our (CodeWeavers's) QA team tests builds and works with me to solve problems over the course of that release cycle. Once we have a build with no known problems, we push it live, and the next
branch goes idle again for a few weeks. Outside of that release cycle window, there isn't a meaningful next
branch to do any testing on.
And there is definitely a cost here, both in terms of developer (my) time and possibly in user confusion. During those couple of days, we usually have 2-5 different RC builds. It's easy to imagine users falling behind and testing a now-outdated build. That means I need to spend time sorting through any user feedback we get to ensure they're not finding an issue that was already fixed in an earlier RC. I also think it would be frustrating for users if I didn't explain what changed in each RC. So that's time I need to spend on user communication (how would this communication take place?). And if an RC build breaks something in the user's prefix, we now need to communicate that to users so they don't continue testing in a broken prefix. There's a lot of added complexity when you're working with the public. It's not something where we just flick a switch and everything is done.
The reason I haven't been doing this is because the release cycle is actually very short. There isn't a long-lived
next
branch where changes are stacked up over weeks. We have a number of developers working on various things in between Proton releases. When we have enough new work to be interesting, I pull all of that work into thenext
branch and begin the release cycle. The time between pulling that work intonext
and pushing the release public is usually 2-5 days. Our (CodeWeavers's) QA team tests builds and works with me to solve problems over the course of that release cycle. Once we have a build with no known problems, we push it live, and thenext
branch goes idle again for a few weeks. Outside of that release cycle window, there isn't a meaningfulnext
branch to do any testing on.And there is definitely a cost here, both in terms of developer (my) time and possibly in user confusion. During those couple of days, we usually have 2-5 different RC builds. It's easy to imagine users falling behind and testing a now-outdated build. That means I need to spend time sorting through any user feedback we get to ensure they're not finding an issue that was already fixed in an earlier RC. I also think it would be frustrating for users if I didn't explain what changed in each RC. So that's time I need to spend on user communication (how would this communication take place?). And if an RC build breaks something in the user's prefix, we now need to communicate that to users so they don't continue testing in a broken prefix. There's a lot of added complexity when you're working with the public. It's not something where we just flick a switch and everything is done.
Awww thank you so much for your amazing job and hard work mister valve ❤
@barfin Decided to give something like this a shot after all. See #3721
Most helpful comment
The reason I haven't been doing this is because the release cycle is actually very short. There isn't a long-lived
next
branch where changes are stacked up over weeks. We have a number of developers working on various things in between Proton releases. When we have enough new work to be interesting, I pull all of that work into thenext
branch and begin the release cycle. The time between pulling that work intonext
and pushing the release public is usually 2-5 days. Our (CodeWeavers's) QA team tests builds and works with me to solve problems over the course of that release cycle. Once we have a build with no known problems, we push it live, and thenext
branch goes idle again for a few weeks. Outside of that release cycle window, there isn't a meaningfulnext
branch to do any testing on.And there is definitely a cost here, both in terms of developer (my) time and possibly in user confusion. During those couple of days, we usually have 2-5 different RC builds. It's easy to imagine users falling behind and testing a now-outdated build. That means I need to spend time sorting through any user feedback we get to ensure they're not finding an issue that was already fixed in an earlier RC. I also think it would be frustrating for users if I didn't explain what changed in each RC. So that's time I need to spend on user communication (how would this communication take place?). And if an RC build breaks something in the user's prefix, we now need to communicate that to users so they don't continue testing in a broken prefix. There's a lot of added complexity when you're working with the public. It's not something where we just flick a switch and everything is done.