Warzone 2100 [part 1 of ?]
Posted: 25 Dec 2016, 05:01
This is more or less a peek inside the dev cycle and how things got done, and how things are currently getting done now.
I am unsure at this time how many of these I would do, but, I feel I need to clear up some things that people didn't know/understand before.
No, I don't expect comments on these posts, that is why it is locked.
Anyway... here is part 1.
Yes, this game was an actual retail game.
It was made by Pumpkin studios, and published by Eidos.
Unfortunately for Pumpkin Studio, they went out of business.
However, the good news (for us at least) was, they (& Eidos) released the source code into the wild!
I will skip the first few incarnations of what became of those versions, since, I wasn't around then.
So, I'll pick this story up from 2.3 onward.
Warzone was hosted on Berlios, then on SourceForge using svn repositories.
SVN was a version control system that made things much easier to keep track of changes and what not, however, after a few releases from the 2.x series, trying to do massive changes with SVN proved to be VERY difficult at best, and often failed when we were attempting to do merges.
We tried to work with SourceForge, but, our project was just too big to be handled via SVN.
We tried Hg, bazzar, and git.
At that time, for widows, Hg was a much more solid product than git or bazzar.
However, the decision was made to stick with git, so, ever since that, that is what we have been using.
We also tried some different git hosts, until we finally settled on Github.
We attempted to do a 3.0 release, which was basically 2.3 with some upgrades do various things, and that ended up being very buggy, so, we never actually made a 3.0 release.
Our basic layout was, we had a "master" branch (aka trunk on SVN), and a 3.1 branch where we would do releases from.
It then became evident that this wasn't optimal, so we then with a 'bugfixes' branch.
The logic went somewhat like this.
We would use 3.1 for releases, but, try to keep it bug fixes only.
Master was used as the testing grounds so to speak.
Bugfixes was just that, it was meant that once we would fix a bug, we would commit to that branch, and then we would have bots commit the same bug fix into both 3.1 & master.
It seemed logical at the time, and it did work as planned, up until it didn't.
The issue then became how do we do new releases now, since 3.1 and master were diverging rapidly.
A ton of work was being done on master, yet, minimal testing was being done, and trying to get ANYONE to test master was very, VERY difficult. Yeah, there were a few people that did actually run master, and report issues to us, and for those people we deeply appreciated their efforts!
So, here we are with a more or less "stable" 3.1, and a vastly untested master wanting to be unleashed as 3.2.
Some thought it was better to keep on 3.1, and backport stuff (basically means to apply some of the newer patches from master into 3.1) from master, yet, others wanted to just release master as 3.2.0.
Yes, it was obvious that quite a few things was broken/buggy, and some downright broken altogether, like the Campaign.
In the end more people wanted to release master than those than wanted the alternative.
We are really a small group of people, with perhaps 1 or 2, sometimes 3 main contributors all working on Warzone 2100 on their free time (No, nobody is getting paid at all! The donations FULLY go to keeping the server alive, which runs forums, lobby server, addons, betaguide, building Warzone 2100 builds, and all that good stuff), and now and then we get some contributors.
Anyway, our old model of maintaining 3 branches (master [for new stuff], bugfixes [for bug fixes that belong in both master & 3.1], and 3.1 [stable]) went out the window, and it was thought it would make much more sense to keep doing releases from master.
It was argued that having featured branches as an expansion of what we have would help, and these feature branches would have specific changes made, and once fully tested, it would be merged back into the main master branch, and the feature branch would be removed. This has not happened yet.
Instead, everything is getting piled into master (for better or worse).
This is where we sit today.
I am unsure at this time how many of these I would do, but, I feel I need to clear up some things that people didn't know/understand before.
No, I don't expect comments on these posts, that is why it is locked.
Anyway... here is part 1.
Yes, this game was an actual retail game.
It was made by Pumpkin studios, and published by Eidos.
Unfortunately for Pumpkin Studio, they went out of business.
However, the good news (for us at least) was, they (& Eidos) released the source code into the wild!
I will skip the first few incarnations of what became of those versions, since, I wasn't around then.
So, I'll pick this story up from 2.3 onward.
Warzone was hosted on Berlios, then on SourceForge using svn repositories.
SVN was a version control system that made things much easier to keep track of changes and what not, however, after a few releases from the 2.x series, trying to do massive changes with SVN proved to be VERY difficult at best, and often failed when we were attempting to do merges.
We tried to work with SourceForge, but, our project was just too big to be handled via SVN.
We tried Hg, bazzar, and git.
At that time, for widows, Hg was a much more solid product than git or bazzar.
However, the decision was made to stick with git, so, ever since that, that is what we have been using.
We also tried some different git hosts, until we finally settled on Github.
We attempted to do a 3.0 release, which was basically 2.3 with some upgrades do various things, and that ended up being very buggy, so, we never actually made a 3.0 release.
Our basic layout was, we had a "master" branch (aka trunk on SVN), and a 3.1 branch where we would do releases from.
It then became evident that this wasn't optimal, so we then with a 'bugfixes' branch.
The logic went somewhat like this.
We would use 3.1 for releases, but, try to keep it bug fixes only.
Master was used as the testing grounds so to speak.
Bugfixes was just that, it was meant that once we would fix a bug, we would commit to that branch, and then we would have bots commit the same bug fix into both 3.1 & master.
It seemed logical at the time, and it did work as planned, up until it didn't.
The issue then became how do we do new releases now, since 3.1 and master were diverging rapidly.
A ton of work was being done on master, yet, minimal testing was being done, and trying to get ANYONE to test master was very, VERY difficult. Yeah, there were a few people that did actually run master, and report issues to us, and for those people we deeply appreciated their efforts!
So, here we are with a more or less "stable" 3.1, and a vastly untested master wanting to be unleashed as 3.2.
Some thought it was better to keep on 3.1, and backport stuff (basically means to apply some of the newer patches from master into 3.1) from master, yet, others wanted to just release master as 3.2.0.
Yes, it was obvious that quite a few things was broken/buggy, and some downright broken altogether, like the Campaign.
In the end more people wanted to release master than those than wanted the alternative.
We are really a small group of people, with perhaps 1 or 2, sometimes 3 main contributors all working on Warzone 2100 on their free time (No, nobody is getting paid at all! The donations FULLY go to keeping the server alive, which runs forums, lobby server, addons, betaguide, building Warzone 2100 builds, and all that good stuff), and now and then we get some contributors.
Anyway, our old model of maintaining 3 branches (master [for new stuff], bugfixes [for bug fixes that belong in both master & 3.1], and 3.1 [stable]) went out the window, and it was thought it would make much more sense to keep doing releases from master.
It was argued that having featured branches as an expansion of what we have would help, and these feature branches would have specific changes made, and once fully tested, it would be merged back into the main master branch, and the feature branch would be removed. This has not happened yet.
Instead, everything is getting piled into master (for better or worse).
This is where we sit today.