Thoughts - Forge and release philosophy

[RumbleBBU]

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.

[RumbleBBU]

Since nobody seems to have followed up on my post (not even to bash it), I'll do it myself and elaborate on my mock-up example. Here's an alternative way of doing it.

Let's assume that we have separate, parallel paths for handling dev and production releases.

The dev releases would continue just like the current Forge releases. All new commits - new features, new cards, refactoring, bug fixes - are automatically included in the next release. Numbering goes like now, from dev-1.0.0 to dev-1.0.1 to dev-1.0.2, etc.

For production releases we want stability and robustness over new features and cutting-edge code. On the other hand, we obviously are interested in new MtG cards and sets. That means we might not wish to update our codebase with the full dev codebase as often as in my first mock-up example. It would be enough if we updated the codebase only when the cards from a new set have been added to Forge. (We would of course, at that stage, also get the new features that have been added since the last update.) After that, we would be applying bug fixes only to the production releases until a new set is added, at which point we would update the full codebase again.

Exceptions could be made for fixes to major problems that require significant refactoring - that could constitute a reason for full codebase update outside the normal cycle.

So basically, let's assume that dev-1.0.0 added cards from a new set. We would take that as the basis for production-1.0.0 and keep adding bug fixes until dev-1.0.1. At that stage we could release production-1.0.0a. Let's further assume that dev-1.0.1 did not add a new MtG set, so we don't update our production codebase. We simply continue adding bug fixes (relevant to the dev-1.0.0 codebase), and when dev-1.0.2 is released, we would release production-1.0.0b. And so on (1.0.0c, 1.0.0d), until a new set is released, let's say with dev-1.0.5, at which point would update the production codebase and start working on production-1.0.5a, etc.

The advantage of this method (compared to my first example) is that the production version would gradually grow more and more stable with every incremental update, from 1.0.0a to 1.0.0b to 1.0.0c and so on, while still offering a reasonably quick access to new sets in production releases.

The disadvantage is that decisions would have to be made regarding which bug fixes are relevant to the current production codebase and which are only relevant to (or require) a later dev codebase (that the production version is not using). The wrong bug fix would probably be either inefficient or even cause new issues.

Again, this only a mock-up version of how things could be handled.

If I have the time to set up a Forge dev environment, I could try to get the full codebase from the SVN when the next beta is out and see if I can make this work for me, manually pulling the bug fixes after that beta. No promises though - the computer I used to code some bits of Forge years ago has been decommissioned since, and I would have to start from the scratch. And yes, I'm a bit pressed on time.

[KrazyTheFox]

While a lot of this is something that would be nice to have, I personally just don't have the time (or energy) after work to manage anything more complex than what's there already. I'm on the hunt for a new job that's not as stressful or dull, so maybe after that I can look into improving the development/bug fix workflow. I'm not familiar enough with subversion to think up the best way to manage this off the top of my head, so that will require some research time as well. We'd also need something that the devs would all agree on and that can be tricky.

[friarsol]

Are users actually going to use the stable builds enough to warrant however much effort is required for it? I think time of the developers is our most scarce resource. I definitely don't have time to spearhead this (usually whoever wants a significant change like this the most spearheads it, but you say yourself you don't have the time). We release fairly often. We don't have a QA team (in a way, our users ARE the qa team).

If stable branch resets only whenever the new sets come out, thats 3 months before re-normalizing with the trunk. The codebase could change so much that bugfixing becomes impossible to merge properly (which basically forces devs to push code to two branches). From what I've noticed people are always gnawing for the latest cards we release, which basically means people might get the stable releases, but don't really want to wait 3 months because someone finally scripts... Shining Shoal (or whatever).


As opposed to having stable bugfixes happening until there's a new stable branch, I could see having an additional release candidate + release a handful of times a year for major set releases potentially working. This is similar to your suggestion but without the "indefinite bugfixing" which has a lot of overhead for devs with limited time.

This scenario starts similarly:
0. Beta releases continue as normal
1. The first beta with a major edition (standard legal) spawns a new "release candidate" branch. We probably don't need two releases for this, it would just be a starting point.
2. Bugfixes are applied to this new branch.
3. After a few weeks, the stable release is posted along with the normal beta release (which may contain new features, etc)

Potentially if this works well, we can attempt a longer term support/release cycle for the stable releases, but starting small has an easier buy-in than trying to go all-in from the beginning.

[RumbleBBU]

First off, my sincere thanks to Krazy and Sol for taking the time to read my posts and respond. Much appreciated.

And yes, I fully acknowledge that since I was the one showing interest in 'stable' builds, it would logically follow that I should be the one to put my money where my mouth is and produce a PoC implementation. I would be happy to try but 1) I am not exactly an SVN expert either and 2) I would need to start by setting up my local Forge dev environment again. Which could take a while, I'm currently heavily involved in a major work project (deadline end of Q2/2017 - yes, it is major).

However, if there is anything at all I can help with to make this become reality, I will be more than happy to do so. Scr*w work!

As for the method, the 'lite' model suggested by Sol seems good to me. Like I said, you would come up with better solutions, and you did. It addresses certain weaknesses in my model, most notably this (which I already recognized when I wrote my second post but forgot to mention):

If stable branch resets only whenever the new sets come out, thats 3 months before re-normalizing with the trunk. The codebase could change so much that bugfixing becomes impossible to merge properly (which basically forces devs to push code to two branches)

So basically, I give my full support to the model outlined by Sol in the post above. And yes, I'm personally willing to do whatever I can to contribute to it. For me, getting a stable release is the top priority, so I'd much rather invest my efforts in that than in new features. What good are new features anyway if the release they are in is not entirely playable?

Time to set up that dev environment again, I guess...

[Agetian]

I completely agree with Sol's idea and I think that that release model might work well given enough dedication from somebody ready and willing to maintain the cycle. It's great that you're willing to try and set this up, RumbleBBU! Given the very limited time most of us have on our hands, we can definitely use all the help possible in setting up a stable/dev release cycle! Good luck and thank you for your ideas and for your effort!

- Agetian

[RumbleBBU]

Don't hold your breath, though...

I had the time to dl the Forge trunk last weekend and try setting up a dev environment again...apparently I had forgotten how troublesome that could be.

I'm getting some weird errors I can't seem to get around. I really don't even remember how I got around them the last time. (Eclipse Indigo + Java 1.8 if that matters.) I'll try to sort that out the next time I have any time...might not be soon.

FWIW, the errors I'm getting are related to java.util.function.Consumer:

Code: Select all

The project was not built since its build path is incomplete. Cannot find the class file for java.util.function.Consumer. Fix the build path then try building this project   trunk      Unknown   Java Problem


The type java.util.function.Consumer cannot be resolved. It is indirectly referenced from required .class files   ListChooser.java   /trunk/src/forge-gui-mobile/src/forge/toolbox   line 1   Java Problem

Tried googling java.util.function.Consumer but nothing particularly useful/helpful came up. Is that something only relevant for the mobile ports, and if so, is there a way to circumvent it for desktop builds?

[friarsol]

I haven't tried to use Eclipse in forever with Forge, it always seemed problematic to me. I'd recommend trying with IntelliJ Idea. No plugins needed, and the whole process is streamlined.

[friarsol]

Alright Rumble, here's the start of your stable branch starting at the Kaladesh release:


http://svn.slightlymagic.net/websvn/lis ... 35bf1ccc66

[RumbleBBU]

Huge thanks...unfortunately Eclipse still isn't working for me

Guess I should try IntelliJ. I don't have a license but the free version ought to be enough for this, or is it?

I really wished I had more time to figure out how to make the current Forge code compile for me. It's grown a lot since I last dabbled with it. I will let you know when I make any progress but worst comes to worst, or even realistically, it might be a release or two later.

[RumbleBBU]

Just to add to that...I want to say that I hugely appreciate the effort - sadly, my dev environment wasn't ready yet. Entirely my fault, I just didn't find the the time or the motivation to try to sort it out when I hit the wall.

I probably will, eventually, but I have no schedule for getting it sorted out. It depends on a lot of things, like my work schedule among other things. I will post again when I got a working dev environment up and running.

[Agetian]

@RumbleBBU: By the way, you can give NetBeans a shot. That's what I've been using since 2011 to develop Forge, and I can say it works damn well with it! You can check out the repo from within NetBeans and immediately compile and run/debug Forge from it without having to install any additional modules or taking any additional configuration steps such as the ones described for Eclipse. Haven't tried IntelliJ, but I remember getting Forge to compile on Eclipse took quite a bit of time (and I switched to NB pretty quickly).

- Agetian

[KrazyTheFox]

The free version of IntelliJ is plenty for Forge.

[RumbleBBU]

Slowly getting there... but not quite there yet.

I'm getting the best results with NetBeans. In short, NetBeans builds Forge for me without much effort on my part. But I just can't get it to run Forge! Yes, I know exactly which Main file I want to use, there just doesn't seem to be any way to tell NetBeans where that Main file is. When I try, it just says "<No main classes found>" and the "Select Main Class" button is predictably grayed out. How do I point NetBeans to the correct Main()? Googling provided no answers applicable to this situation.

I'm also getting an error message about there not being enough space in the temp folder for downloading and unpacking the index for 'Central Repository', whatever that is. The drive where I manually set my temp folder to has over 3 GB free, and the temp folder data doesn't seem to be using much of that. Is this error something I should be worried about?

I'm hoping to get these issues sorted out finally so I could try a stable 'PoC' with 1.5.57 (it already seems to late to try that with 1.5.56 with 1.5.57 waiting in the wings).

Any help will be greatly appreciated...

[friarsol]

What made you give up on IntelliJ? Can't really help with NetBeans, never used it.