Project Zomboid New Release Method

Hello everyone! There hasn't really been a whole lot to post about as of recently because it seems most people are enjoying the holidays and spending time with their families this time of year before getting back to the grindstone.  I found this post about the future updates of Project Zomboid interesting so I thought that I would share it at watchsurvival.  Update releases for Project Zomboid have been on halt as they are getting ready to release the smoothest and most features added version of Project Zomboid yet. The long release time has a lot of people worried about future updates as well and the lead developer has released a post ensuring people that future updates will be a lot more faster because of the new system of development.  Alas, good things come to those who wait as they say. The full post and discussion can be seen below or you can read the copy and paste version of it here.

http://theindiestone.com/community/viewtopic.php?f=20&t=11334


--copy and paste of developer post--

New Release Method - Why it'll allow for weekly snapshots

 So once the next version finally goes live, with it will come a more solid, reliable release system that will enable us to release stable builds every week. Some people seem to think this is hot air, so I'll explain exactly why this is the case.

The game has an SVN repository which stores the code for the game (offsite, yes ). This is the code-base the game is built of, that evolves as code is added / changed. Supposing after this build, we start adding multiplayer. Under the old system, with some carefulness, it would be possible to do chunks of multiplayer amidst other updates, but after a certain point, there would be a fundamental change that would be the first step in a series of changes that would break the game until they were complete.

This would probably result in a delay. After that 'point of no return' it would be difficult to do bug-fixes, even if they were already in the build.

So the new system we will be employing is thus.

We have two completely separate SVN repositories, each with their own set of source code for the game.

One of them is the development build. One of them is the release build.

So when RC3 is released, people rejoice.

The team get to work coding multiplayer on the development build, and in the process break an element of the game which would make the development build unreleasable. This is where problems have started with major feature additions in the past.

But there's a bug! A serious bug. What to do?

But it doesn't matter, because the process is thus (admittedly it'll take a little longer) to fix the bug on the development build, but then transfer the bits of code for the bug fix into the release build.

Then say a new cell of the map is complete, that's done in the development build, and copied across to the release build.

We keep doing this, meanwhile continuing work on the multiplayer. By now numerous game systems are broke because of requiring reorganizing into client / server, but it doesn't matter. The development build never needs releasing directly, because every finished addition to the game, and every bug fix, is first applied to the development build, but then additionally transfered to the release build. The release build has none of the multiplayer code breaking anything, and never stops working.

6 days go by (or sooner if the bugs are serious) and then we make a build of the release build and have a day of testing. It all seems to work dandy.

and on the 7th day, we release.

This process is repeated for weeks, maybe months. One day, multiplayer is working. We now make a build of the development build. We put that into testing for a week or two, and if everything works as planned, we release that, Call it release 1.1 or something.

Then we copy the development build over the top of the release build. Now both SVNs are synced.

Then the process starts again, we start developing other major features in the development build, and if any bugs with multiplayer pop up, or new map cells or anims are complete in the meantime, we add them to the development build and merge them into the release build.

Because of maintaining two completely separate builds, there is never a time when the release build stops being eligible for release. Not for one moment. There's never a 'we can't release till we do X' and there's never a moment where a big change wreaks havoc causing a multitude of bugs risking save games or whatever, since we can do more vigorous testing on the development build to make sure it's solid and it's not slowing down the release build.

Maybe we're idiots for not doing this before. It's the system the company Romain works at (besides us ) uses, and frankly it was news to me. Ironically I may have had a lot of development experience at an in-house games studio, but developing directly for customers is newer to me so I guess this is the reason such a system wasn't in place prior to Romain's suggestion.

But the fact remains, this will work. It's not an empty promise or even over optimism. This WILL mean, uninterrupted weekly snapshot builds, where a delay would mean a day, or a weekend.

Sadly, for a multitude of reasons, it's not feasible to start doing before the next release.

Hopefully this fills people in who are thinking we're blowing smoke. If some other forumites with dev experience could confirm that the system is pretty water tight for those that don't, would appreciate it.