Thoughts - Forge and release philosophy
Posted: 19 Aug 2016, 05:55
First, I would like to explain why I am writing. My intent is by no means to disparage all you great people who keep sacrificing your time and effort to make Forge even greater. You have my deepest gratitude and respect. I can never thank you enough, so...thank you!
There is, however, one major difference between how Forge is being developed and pretty much every other software project that I've participated in (at least as long as we are only counting software that had publicly available releases). Most other projects had separate "production" and "dev" branches, to some degree or another. The idea was that we wanted to 1) keep adding new features and improving the underlying engine all the time, but also 2) offer public releases that were reasonably stable and not totally messed up because of recently added functionality that had not been thoroughly tested or even finished yet. There were several ways of doing this, depending on how separate we wanted to make the "dev" branch from the "production" branch. In some projects, we would even make separate "dev" releases for people who were eager to have all the most recent goodies even when that meant that the software could be very buggy, crash without warning, corrupt data and do various wildly random things. Caveat emptor, "use at your own risk" kind of stuff.
Forge only has one main trunk that is basically both a "dev" version and a "production" version. In theory, this could work. But inevitably, there will sometimes be problems when new functionality is added between versions. Given the complexity of the game system and all possible interactions between the thousands of cards, it would be obviously impossible to test for every contingency when introducing new code. Which leaves a lot of room for things to go wrong.
And they have gone wrong more often than not. In fact, I cannot even remember the most recent release that didn't contain some significant bug that was detrimental to my playing experience or rendered some aspect of the game (or some cards/card combinations I like to play) unusable. (Or actually it seems I can remember...it would be version 1.5.17, I guess. I still have that version somewhere...because of that!)
Granted, things used to be much worse in the past, when a release could wreck not just certain kinds of cards but major core functionality. But to be honest, I have been a little disappointed with how the more recent releases have turned out. I have been upgrading to new versions hoping that they would fix the annoying bugs in the current version, or at least some of them. Yes, they have done that. But they also always seem to break something else instead. Always. (Bummer.)
Which is why I started wondering: why couldn't there be separate "dev" and "production" versions of Forge? Dev releases for people who must have every new card and feature, production releases for people who appreciate a more stable playing experience and can afford to wait.
Here's a simplistic example of how two parallel releases could be managed: (this example is obviously a total mock-up and not a proposed 'ideal solution')
1. A new dev version is released, lets call it dev-1.0.0.
2. New commits are made after the dev-1.0.0 release. All of them are applied to the dev branch but only bugfixes are applied to the production branch.
3. Time for the next release. Two versions are released: dev-1.0.1 (contains all commits since dev-1.0.0) and production-1.0.0 (which would be the same as dev-1.0.0 with bug fixes applied).
4. The cycle starts again. The dev-1.0.1 code is now used as the base for new dev and production commits.
So, in this model, the production version would always be "one release behind" the dev version. And more stable than the dev version with the same release number.
There would be some obvious problems with this approach, like,
- More work. Some of the work (like the extra "production" build) could probably be automated.
- More storage space required.
- Sometimes a bug fix requires major refactoring or rewriting of current code. In these cases, even the bug fix might have to wait until the next version.
- Yes, only applying bug fixes is obviously not guaranteed not to break anything. But major new functionality and refactoring is much more likely to do so.
Personally, though, I believe it would be worth the effort in the long term. I don't think I would be the only player would gladly trade the latest in-the-works features (and even the newest cards) for a more stable playing experience.
Of course since I am not totally clueless at software building, I could simply manually pick the bug fix commits only from the svn and apply them. But that's a lot of manual work. And people who do not code would not even have that option.
I wish to emphasize, I am definitely not implying that what I proposed above is the best or the only solution. What I'm trying to say is that the problem is real, and that could be one way to tackle it. You may come up with something better, and probably will.
If there is anything I could do to help this (a dev/production model or something similar) become reality, I would be happy to contribute.
There is, however, one major difference between how Forge is being developed and pretty much every other software project that I've participated in (at least as long as we are only counting software that had publicly available releases). Most other projects had separate "production" and "dev" branches, to some degree or another. The idea was that we wanted to 1) keep adding new features and improving the underlying engine all the time, but also 2) offer public releases that were reasonably stable and not totally messed up because of recently added functionality that had not been thoroughly tested or even finished yet. There were several ways of doing this, depending on how separate we wanted to make the "dev" branch from the "production" branch. In some projects, we would even make separate "dev" releases for people who were eager to have all the most recent goodies even when that meant that the software could be very buggy, crash without warning, corrupt data and do various wildly random things. Caveat emptor, "use at your own risk" kind of stuff.
Forge only has one main trunk that is basically both a "dev" version and a "production" version. In theory, this could work. But inevitably, there will sometimes be problems when new functionality is added between versions. Given the complexity of the game system and all possible interactions between the thousands of cards, it would be obviously impossible to test for every contingency when introducing new code. Which leaves a lot of room for things to go wrong.
And they have gone wrong more often than not. In fact, I cannot even remember the most recent release that didn't contain some significant bug that was detrimental to my playing experience or rendered some aspect of the game (or some cards/card combinations I like to play) unusable. (Or actually it seems I can remember...it would be version 1.5.17, I guess. I still have that version somewhere...because of that!)
Granted, things used to be much worse in the past, when a release could wreck not just certain kinds of cards but major core functionality. But to be honest, I have been a little disappointed with how the more recent releases have turned out. I have been upgrading to new versions hoping that they would fix the annoying bugs in the current version, or at least some of them. Yes, they have done that. But they also always seem to break something else instead. Always. (Bummer.)
Which is why I started wondering: why couldn't there be separate "dev" and "production" versions of Forge? Dev releases for people who must have every new card and feature, production releases for people who appreciate a more stable playing experience and can afford to wait.
Here's a simplistic example of how two parallel releases could be managed: (this example is obviously a total mock-up and not a proposed 'ideal solution')
1. A new dev version is released, lets call it dev-1.0.0.
2. New commits are made after the dev-1.0.0 release. All of them are applied to the dev branch but only bugfixes are applied to the production branch.
3. Time for the next release. Two versions are released: dev-1.0.1 (contains all commits since dev-1.0.0) and production-1.0.0 (which would be the same as dev-1.0.0 with bug fixes applied).
4. The cycle starts again. The dev-1.0.1 code is now used as the base for new dev and production commits.
So, in this model, the production version would always be "one release behind" the dev version. And more stable than the dev version with the same release number.
There would be some obvious problems with this approach, like,
- More work. Some of the work (like the extra "production" build) could probably be automated.
- More storage space required.
- Sometimes a bug fix requires major refactoring or rewriting of current code. In these cases, even the bug fix might have to wait until the next version.
- Yes, only applying bug fixes is obviously not guaranteed not to break anything. But major new functionality and refactoring is much more likely to do so.
Personally, though, I believe it would be worth the effort in the long term. I don't think I would be the only player would gladly trade the latest in-the-works features (and even the newest cards) for a more stable playing experience.
Of course since I am not totally clueless at software building, I could simply manually pick the bug fix commits only from the svn and apply them. But that's a lot of manual work. And people who do not code would not even have that option.
I wish to emphasize, I am definitely not implying that what I proposed above is the best or the only solution. What I'm trying to say is that the problem is real, and that could be one way to tackle it. You may come up with something better, and probably will.
If there is anything I could do to help this (a dev/production model or something similar) become reality, I would be happy to contribute.