It helps to understand a little bit about the complexity of software management, especially where multiple components have to be kept in-sync. In this case the big problem is keeping the PC and Mac clients in sync with the server and each other without providing a moving target for the Mac port guys. In general, even without these extra constraints, the software development lifecycle isn't straightforward. Think of it like this: ED is split into multiple parts:
- The server. The interface to the server will generally remain consistent, though APIs will necessarily change.
- The engine. Frontier will have a team working on the game engine, providing interfaces for the game logic developers to hook into. The majority of the differences between the Mac and PC ports will be here.
- The game logic. This should be stuff that's client-agnostic, e.g. AI, HUD layout, stellar forge, etc.
- Art / audio assets. The game logic hooks into these, interfacing with the engine to display them.
A bug fix may require changes to all of these parts.
A software project usually consists of a 'trunk' (the main development stream) and a number of 'branches'. When a branch is made, a snapshot of the project is taken, and work done on that branch is then relative to the snapshot. Branches can be branched, so you can presumably see where the terminology comes from.
In Frontier's case, the trunk will effectively be the next intended release. Bugfixes and features are generally done on branches, usually tested in isolation on that branch, then those changes merged back into the trunk. Sounds simple, but it rarely is. The trunk will be ever-moving. Whenever someone merges to trunk, those merged changes may also affect files that you've touched on your branch. When this happens you have what's known as a 'conflict'. Merge tools generally can't decide what's the best course of action to resolve a conflict, so will push the decision back to the programmer. When you have a large, dispersed team like Frontier, this problem is exacerbated. So, software development with multiple streams is hard. You can keep on top of the branch/trunk paradigm for normal development if it's managed well (and that appears to be the case with Frontier). So why do we get decreasing bugfixes over time?
The answer to this is that when Frontier do a release, *this becomes a branch*. They take a snapshot of the trunk at the point of the release, and from that point on development continues. When a bug is found in the release, they will generally either fix it based on the trunk or on the release branch. This change must also then be merged into the other stream (e.g. if done based on trunk, it needs to be merged into release, or vice versa). As time goes on, the release branch and the trunk diverge more and more to the point where a bugfix may require multiple implementations -- one for the release branch and one for trunk. Frontier have to take the decision whether it's worth doing the same work twice -- they'll do this if it's a game-breaker -- or to do the bugfix once relative to trunk and not do it on the release branch. As time goes on and the divergence increases, the effort required to maintain the release branch increases to the point whereby it would be detrimental to development of the game to maintain it.
Some bugs take longer than others to isolate and/or fix. Some will require significant refactoring of the software. I'm an experienced software developer, and Frontier never fail to amaze me when a major release comes out. The amount of work that they get done, and the overall quality of that work, is incredible. I'm prepared to have my socks blown off once again when 1.3 is released.
