-
1 Votes1 Posts543 Views
-
2 Votes17 Posts2k Views
-
1 Votes15 Posts3k Views
-
4 Votes10 Posts2k Views
-
0 Votes3 Posts862 Views
-
2 Votes25 Posts4k Views
-
0 Votes8 Posts2k Views
-
1 Votes2 Posts899 Views
-
1 Votes1 Posts752 Views
-
0 Votes8 Posts2k Views
-
0 Votes10 Posts1k Views
-
0 Votes5 Posts882 Views
-
2 Votes6 Posts2k Views
-
1 Votes32 Posts10k Views
-
1 Votes14 Posts2k Views
-
0 Votes27 Posts7k Views
-
0 Votes7 Posts1k Views
-
1 Votes7 Posts1k Views
-
2 Votes2 Posts728 Views
-
1 Votes7 Posts1k Views
Recent Posts
-
@LaFayette What happens if there is bad update, that breaks part of the game. How can we go back to good prerelease version?
-
@LaFayette ok so maybe all that wud be needed at this point then since the menu is icons i’d reverse the up arrow that wud make it more obvious that thats where you go to download
-
@ubernaut we kinda hijacked this thread, but be what it may - finally found where those links are defined. They are only at the bottom of the "recent topics", AFAIK only displayed exactly on the homepage. I removed them all, it's not a place to really expect to see a lot of links and they require maintenance and are a bit dubious...
-
And I guess the maintainer/maintainers will retain the capability of skipping a scheduled recommended release if they feel like it's better not to (in case the current release having some serious regressions).
If the upcoming recommended release has a serious regression, then so would the version that the new players are downloading. The way to deal with regressions will be to immediately start rolling back code updates until the regression is removed. It's easy to restore those code updates, but the reaction will be to start rolling back as soon as any issue is discovered and then roll forward with a confirmed fix. Thereby, regressions should be resolved essentially immediately, not with fixes, but with rolling back. That buys time for doing a fix properly, avoids trying to patch broken code with potentially more broken code, and reduces how many other updates that go into the code base that could be broken themselves (it's a lot easier when something breaks if it's obviously the last thing that was merged, it's a lot more difficult when we are testing for the first time months after the fact and there are multiple things interacting with each to cause a breakage)
How about the recommended release being automatically skipped if there is one or more open GitHub issues with the "Regression" label on it?
That idea was floated, the regression label might become obsolete. It will depend how significant an issue is, but generally the response will be to remove all recent code updates until the culprit is removed.
(I obviously also assume the recommended release will not happen if it is the same as the previous one, like in case it is seasonal and no new version of TripleA was release in 3 or more months. Right?)
This is in part a rationale for 6 month cadence. Helps avoid that situation and reduces the frequency for players being asked to update