Fixing the Branches, Or, How to Move Forward

[QuintillusCFC]

We're in a bit of a situation currently - there are three "main" branches, all of which are in different states:

• Development, aka the Godot 3.5 branch. This is the stable one, everything that ever worked in C7, works on this branch.
• godot4. This is based on Godot 4 (4.1.1 it the latest I've run it on). Still has a few issues, primarily around fonts, but some others as well such as a translucent gray rectangle around cities. Much better than it was but never got fully fixed-up.
• pcen/use-tilemaps. Based off of Godot 4, it uses performance-enhancing tilemaps for rendering. Unfortunately, this switch also introduces some other fidelity issues that weren't present/were fixed in godot4, and which aren't present in Development.

We also have a plethora of open PRs, whose merge hierarchy is difficult enough that I made a flowchart to visualize it (updated since the original post):

The colors are:

• Blue: godot4 branch to main, and fixes to that branch Note: 414 has since been merged.
• Green: pcen/use-tilemaps branch to godot4, and fixes to that branch
• Yellow: Save functionality related changes. These are currently pointed to merge in through tilemaps, and thus through godot4.
• Gray: Feature enhancements/fixes that weren't present in Godot3, and are currently pointed to somewhere other than Development
• Pink: PRs pointing to the Godot 3.5 based Development branch

---

First I'll add the philosophical interlude - how'd we wind up here and where'd we go wrong? Well, part of it is that this isn't anyone's job, but similar issues can crop up when the software in question is someone's job. To me, the following things stand out once it's all color-coded:

• Three major features - godot4, tilemaps, and saves - are all in progress. We don't have enough active contributors to keep all of those moving.
• tilemaps does depend in Godot4 (or at least, we never considered adding it based on the Godot3 engine), so that dependency makes sense. However, it is based on a not-yet-ready-for-prime-time godot4 branch
• Save files is a key feature, but should be almost all back end, with the UI that might vary based on Godot3 vs 4 being a small part. Yet it depends not just on Godot4, but on the tilemaps as well, meaning even if it's ready to go, it cannot be shipped until both of those are ready.

My "hindsight is 20/20, we weren't working in the office together" recommendation would have been to have Godot4 stable before starting on tilemaps, and to have the back-end parts of the save working off of the Develop branch, with an optional side branch that cherry-picks it over to a branch off of Godot4 for testing the UI part of it there. Issue 430 likely also should have been based off of Development until godot4 was ready, but it doesn't have other issues waiting on it, so that's minor.

Unfortunately, now we have a lot of changes building on what was not yet a stable foundation - issue 414 being the only one that properly "should" be on the 409 foundation while it's still waiting to merge. This is classic waterfall development, creating a new version and working on everything at once with the expectation that the foundations can be ready to go before it's time to release everything; unfortunately when you don't have a paid team working on the project, that increases the likelihood that things get abandoned because it's hard to untangle the halfway-finished parts if you aren't looking at them every day.

---

More practically, how do we resolve this situation? Personally, I'm inclined to just move forward with the Godot 3.5 "Development" branch, because it's stable and IMO our best chance of winding up with a playable game. The save-related code, 423, 425, and 426, can likely be ported over to that Godot 3.5 based as most of the code will be logic rather than UI, and I think that's actually the last significant item on the "Carthage" milestone - and also a huge step towards a playable game. Issues 402 and 430 (once PR comments are resolved) can also be redirected to work on 3.5, although 402 might require a somewhat different solution.

Then, 3.5 will be free to advance, sustaining interest in the project, and at the same time, the Godot 4 branch can be brought up to parity with Godot 3 from a feature/stability/fidelity standpoint. Once it is brought up, we can re-merge any new features that have been added to 3.5 in the mean time, and repeat that process with shorter and shorter differentials until we can release based on Godot 4. This could be in two months, two years, or never. IMO, even "never" is acceptable, as Godot 3.5 was working fine, is still listed as the LTS (Long Term Support) release on Godot's website, and it's not like we need bleeding-edge technology anyway.

But once the Godot 4 branch is stable and our main one, effort can return to tilemaps. It's a good idea, but it needs to be based on a stable foundation. And that stable foundation is also important to making the project attractive to new members - both in having a solid place to start, and in sustaining activity.

Of course, if someone would like to dive into the godot4 branch and make it the new stable foundation, I'm not going to stop them, but it's been 13 months since the Godot 4 branch was started. IMO, it's more likely that the project will wither and die on the vine of engine migration than that it will move forward should the status quo continue, and as someone who wasn't really involved in the Godot 4 code, my inclination to dive into that area is low.

[pcen]

Godot 4 branch has been stale for so long mainly because I haven't worked on it in a long time. I need to refresh myself, but I think for the most part it's very close to parity with 3.5 now. I'm inclined to tackle some of the issues in #441 to try and get it stable. My 2 cents is that Godot 4 is getting a lot of development, and the influx of Unity developers will develop on Godot 4, so I think it's worth investing in finishing the migration, especially since I think we're close

[WildWeazel]

I believe this is mostly OBE, but #407 has NOT yet been merged. Aside from its own conflicts with godot4 Development, is there anything else left to untangle?