Check everything double and twice. Once it is out, you may not touch your mod or release Quickfixes without adding additional hassle, so be sure to get it right the first time. Depending on how your team is organised speak with everyone responsible for their things. check the graphics, physics, sounds and also the meta stuff like Installers, READMEs and Credits. Be sure to have everything covered and the latest version of everything. And I suggest to be sure days before your release, not on release day.
Package the mod. There are debates on the how. Many don’t like exe-installers, they are convenient, but often they leave traces in the system and cause problems. If you use it, trust your installers, test them thoroughly, also test uninstallation of your mod! Installers may neither replace nor delete configuration files. Be sure of that!
Others just pack it in a large compressed archive. You can also archive your exe-installer, many upload sites don’t allow *.exe, so something else is recommended.
Since CTDP F1 2004 we use 7zip as our compression file format. It’s Open Source and the strongest compression format we know. Especially redundant data like uncompressed textures can be reduced to a fraction of the original size. This way we got the 2004 Expansion pack down from 1.5Gb to 40mb! For rFactor it’s less effective, since rFactor already applies some compression, but still F1 2006 was reduced from 4.8Gb to 1.3Gb. Note, encrypting models and mas-files reduces the effectiveness of compression algorithm, since the encryption tries to increase enthropy, thereby decreasing compressible patterns.
During the download of a mod, there can be errors in the network. Bits get flipped and corrupt the archive. Most regular HTTP-download tools can’t check this and the user can only see it when the archive doesn’t work. While you can’t make sure the download works alright, you can make help to let the user check the archive. When you have your final package calculate MD5-checksums and release them together with the mod. The user then can run the checksum on their downloaded archive as well and if it matches everything is alright. It doesn’t prohibit problems, but it can help to identify them. However only few people will actually use this.
If you are good, you leave one day off between packaging the mod and releasing it. If no bugs are find in this period, you are pretty good to go.
A release can last for up to 12 hours and puts you under alot of adrenaline, enjoy it!
You are dealing with alot of people on this day, with your mirrors and webmasters, you team mates and there is always something to do. Relax! A release is a delicate procedure and half an hour earlier or later doesn’t matter that much. A release can be physically exhausting and requires a lot of concentration. So have some snacks and beer for the celebration afterwards ready. 😉
You have your packaged mod. You have all your mirrors. The mod is uploaded in private to all mirrors. Your news messages are done and ready. You have everything under control.
The most elegant way is to prepare everything, so you only have one switch at the end. Prepare your website, but leave the blog-articles private. Have the download links ready, but invisible. Have everything as simple as possible to go live once the green light is given.
Make it one switch to put everything live. No hassle dragged over several hours.
Be in a team meeting, discuss the status of the uploads, packages, whether there were any short-notice bugs and decide if you go for the release or if there is any reason for postponement. This is like NASA sitting in mission control, everything is ready and everybody is waiting for the final GO or NO-GO.
If you have a GO, you can publish the news and put the links online. In the mean time other members can start posting in forums and begin seeding the torrent-release. Once the switch is flipped, there is no going back.
You are releasing the pride you have been working on for god knows how long.
This is your moment in the sun, your 15 minutes of fame!
This is what you and your team has been working and waiting or months or even years. Enjoy it!
Releases don’t happen to often. Mod projects can be quite large and should be celebrated.
Be together with your team-mates, have a (virtual) party, take out your beer and enjoy the evening! Don’t let anything bad come to you and ignore any bad comments. They can be sorted out later.
Once the switch is flipped, there shouldn’t be anything you can do.
Just wait for the flood to come and see what problems arise. Collect problems, deal with them later. For the community releases are chaos, because so many people download and comment, that it’s hard to keep track of the news anyway. They try to find download links and get it working as soon as possible. Even if there are problems, don’t disturb this and so don’t bring quickfixes. Some smart people in the community will do so anyway if it’s obvious and severe. Otherwise, you just worsen the situation, because people aren’t sure whether to download the fix and what the actual problem is.
Instead, wait till the comments calm down and address issues for example in your blog, where people can read it. In general, try to improve overview, answer questions and try not to add more problems to the mix by quick reactions.
A few days after the release, it’s always worth noting, what worked what didn’t. Try to identify the biggest problems and how you can address them the next time. Releases are always a matter of experience and CTDP had their bloody noses and if we don’t pay attention, the next bloody nose could be a few weeks away.
This was the final chapter of our tutorial about How to release a mod. I hope you enjoyed it and that it helps you consider issues you might have during your next release.