Re: A constructive discussion about stability, patches and bug fixes
Posted: Wed Jul 01, 2026 7:14 am
Right, before diving into the core issue, let's get some fundamentals out of the way.
------------------------------------
* Every time this subject comes up, there is a suggestion about halting development of new features until a certain arbitrary theshold of "quality" is reached. This is not going to happen. Command has to keep moving forward and evolving in order to adapt to its evolving environment and market, both on the civ and pro sides. Putting a pause on new development would benefit exactly one group: Our competition. We're not about to hand them a freebie.
Bugs are a fact of software life. A big chunk of software development is about managing them while also moving forward (refresher). And yes, new features can (/will inevitably?) introduce new bugs. But without new features, software stops evolving to changing needs and requirements. (Why is almost no-one playing [computer] Harpoon right now?)
* Yes, Command is "unfinished". So is the OS of the device you're using at this moment. So is the web browser you are reading this thread with. (If you're not regularly updating your OS and your browser: Our condolences, and good luck). "Unfinished" is another term for continously being developed to improve with new features requested by the users and market, fixes to known issues as possible, and general improvements to the underlying codebase. There is an easy way to marvel at finished software: Browse your favorite abandonware site.
* We are very proud of the progress we've made on delivered quality the last 5-6 years or so. Anyone who's been with us for a while (such as Figeac himself, we hope) can recognize this. We have streamlined our internal development, collaboration and branching processes, expanded our internal QA team, *vastly* increased our testing coverage and automation (including internal scenarios for common issue cases), and introduced several new measures for preventing most common cases of failure. We've even consciously made "Snow Leopard"-like official releases (such as CMO v1.07) where the focus has explicitly been on improving the existing codebase and fixing issues rather than introducing new functionality. This is not to claim perfection by far; but to underline where we are: at a much better place than, say, 2020 or 21.
* Beta releases (both private and public) are inherently more "adventurous". New features are often present and still raw/unrefined, existing code is optimized or re-architected, new ideas are tried out etc. This almost invariably means new bugs, and sometimes old "friends" popping up again. This is part of the reason they are not for everyone. We would like to think our official releases have been pretty stable, particularly since v1.07, but this is a judgement call that we prefer that the player community make for themselves.
-------------------------------------
Now then, onto the main point: Why are there voiced concerns about long-persistent and regressing issues? Particularly since internally we are, in fact, checking for such problems before each release?
My suspicion is that the root cause of the problem is this: That the scenarios used internally to check for problems, and the scenarios "in the wild" where the long-persistent and regressing issues mostly manifest themselves, are not one and the same.
If we accept this as a major part of the problem, then a major part of the solution presents itself: Make these scenarios one and the same.
For this reason, I am inviting those who have experienced such issues (Figeac as the OP but also anyone else) to share their specific scenarios/saves with us. We will take them and try to add them to our existing internal test suite. (I say "try" because not every simulated predicament lends itself to instrumentation for efficient testing). If we are able to, these will become a permanent feature of our pre-release testing pipeline.
Does this guarantee that the problem in question will be eradicated and/or not resurface? No, but it does mean that the dev & QA teams will at least have an opportunity to catch it prior to it re-appearing in the wild and causing the heartache so obvious in this thread.
Open to reasonable suggestions.
------------------------------------
* Every time this subject comes up, there is a suggestion about halting development of new features until a certain arbitrary theshold of "quality" is reached. This is not going to happen. Command has to keep moving forward and evolving in order to adapt to its evolving environment and market, both on the civ and pro sides. Putting a pause on new development would benefit exactly one group: Our competition. We're not about to hand them a freebie.
Bugs are a fact of software life. A big chunk of software development is about managing them while also moving forward (refresher). And yes, new features can (/will inevitably?) introduce new bugs. But without new features, software stops evolving to changing needs and requirements. (Why is almost no-one playing [computer] Harpoon right now?)
* Yes, Command is "unfinished". So is the OS of the device you're using at this moment. So is the web browser you are reading this thread with. (If you're not regularly updating your OS and your browser: Our condolences, and good luck). "Unfinished" is another term for continously being developed to improve with new features requested by the users and market, fixes to known issues as possible, and general improvements to the underlying codebase. There is an easy way to marvel at finished software: Browse your favorite abandonware site.
* We are very proud of the progress we've made on delivered quality the last 5-6 years or so. Anyone who's been with us for a while (such as Figeac himself, we hope) can recognize this. We have streamlined our internal development, collaboration and branching processes, expanded our internal QA team, *vastly* increased our testing coverage and automation (including internal scenarios for common issue cases), and introduced several new measures for preventing most common cases of failure. We've even consciously made "Snow Leopard"-like official releases (such as CMO v1.07) where the focus has explicitly been on improving the existing codebase and fixing issues rather than introducing new functionality. This is not to claim perfection by far; but to underline where we are: at a much better place than, say, 2020 or 21.
* Beta releases (both private and public) are inherently more "adventurous". New features are often present and still raw/unrefined, existing code is optimized or re-architected, new ideas are tried out etc. This almost invariably means new bugs, and sometimes old "friends" popping up again. This is part of the reason they are not for everyone. We would like to think our official releases have been pretty stable, particularly since v1.07, but this is a judgement call that we prefer that the player community make for themselves.
-------------------------------------
Now then, onto the main point: Why are there voiced concerns about long-persistent and regressing issues? Particularly since internally we are, in fact, checking for such problems before each release?
My suspicion is that the root cause of the problem is this: That the scenarios used internally to check for problems, and the scenarios "in the wild" where the long-persistent and regressing issues mostly manifest themselves, are not one and the same.
If we accept this as a major part of the problem, then a major part of the solution presents itself: Make these scenarios one and the same.
For this reason, I am inviting those who have experienced such issues (Figeac as the OP but also anyone else) to share their specific scenarios/saves with us. We will take them and try to add them to our existing internal test suite. (I say "try" because not every simulated predicament lends itself to instrumentation for efficient testing). If we are able to, these will become a permanent feature of our pre-release testing pipeline.
Does this guarantee that the problem in question will be eradicated and/or not resurface? No, but it does mean that the dev & QA teams will at least have an opportunity to catch it prior to it re-appearing in the wild and causing the heartache so obvious in this thread.
Open to reasonable suggestions.