I meant specifically the network protocol. I can't think of any other place where we should focus on maintaining backwards compatibility if there's a better way to handle something in Godot. That includes maps and cockpits. If there's a better way to do it in Godot, we can and should.Z-Man wrote:Backwards compatibility: The thing I want to avoid by postponing the decision is that sticking with compatibility limits our design choices for the new thing. For example, compatibility with the old setting system with its flat organization would make it more difficult to distribute settings better over the whole scene tree with, for example, the possibility to make the cycles of one team faster, but those of the other team more maneuverable or with some other advantage.
I was thinking about the beta cycle around 0.2.8's first release. Having 0.2.7.1 and 0.2.7.0 (and the occasional 0.2.6.1 client) being able to connect and use the beta servers gave us a big practical advantage for testing server stuff, and I'd hate to lose that in the cycle from 0.4 to 0.6, although if we found that a majority of the community switched to the 0.5 development series, even then I might not worry about maintaining network compatibility anymore.
And this time around, it could be planned in advance so we could get both frame-limited recordings (and the ability to render screenshots as a job so we could make videos for places like youtube) and debug recordings that give you the whole game state.And heh, one of the first things we need back would be debug recordings. I don't want to simultaneously debug client(s?!) and server that way.