Since I was locked out of the other thread I start this one which is only centered around how larger professional teams handles the issue of maintaining software.
First of as a engineer you dont guess. You always make calculated decisions rooted in deep analysis. That means you always have a migration branch with latest versions of your code and dependencies (In this case Unity game engine). You can then keep your issue board up to date with whats need to be done to migrate and you can now start to look at the cost.
Keep in mind, not migrating is almost always at a higher cost. Only none significant software like small tools etc can be left unmaintained (maybe).
You are saying that not upgrading to latest version of engine has incurred a higher cost… presumably a higher cost than not upgrading. What is this cost? Lost revenue? Falling behind competition?
I commented in the other thread but deleted when your comment was removed, since it broke up the flow of the thread. So here it is again.
I think it’s very simple. If you have a game that you want to update regularly over a long period of time, such as a big multiplayer game sitting in early access for an undetermined long period of time, it makes sense to create your mega branching git update factory. In that context, it improves your workflow since the ‘capital cost’ and the ‘overhead cost’ of doing production this way are offset by the fact that you will likely want or need to use new versions of Unity to take advantage of features and improvements. The infrastructure you build will be used many times, and pays for itself eventually.
If you’re doing a small game with a 2-3 month production cycle, that you don’t plan to add anything to after it’s finished, like the OP of the other thread was doing, there’s no need to start off with that kind of workflow. Such a thing would be the exact opposite of ‘agile’, it would slow everything down, and it would hardly get used.
If someone has a small game and would like to simply have it working in latest Unity, it’s enough to sit down every now and then, bring it into the latest Unity, and fix the issues that pop up. No amount of git branches will change the fact that when something breaks, you have to fix it and it probably won’t be fun.
But the guy wanted to revive the game (Unpanned I imagine). So it invalidetes what you say. If he kept it on UNity 3 your assumption would be correct. But now he wanted to move to a x64 supported version.
About the branching strategy, why not do it the correct way if you are going todo it? Its much easier. You can easy stash changes, revert, compare, etc, etc.
The cost can be anywhere from longer dev time (It takes longer time doing everything in one haul than incremental small updates) to total scrap of current project.
What do you mean by ‘revive’? Essentially he needed to get it working in the latest Unity. The simplest way to do that is simply to sit down and upgrade it. It’s something he hadn’t even thought about for four years.
If you aren’t going to do anything with a game for four years, all the update infrastructure you build will be sitting there doing nothing. This is something he would only ever need to do once or twice in the course of many years. What’s the point of the git branches? By the time he got around to using it, Git would probably have introduced some breaking change of their own, and wrecked the project even more.
These are the questions you ask when you want to be ‘agile’.
There is no ‘correct’ way. I believe in the idea of putting effort where it counts and where it will pay off. Given how much you seem to value the idea of agility, I thought this would be something you’d agree with.