Release process for 0.2.8_beta1

[Z-Man]

As warned in the long 0.2.8 thread, I tagged the sources for the first beta release of 0.2.8. The tag name is v0_2_8_beta1. I tagged all modules; should you notice during building that some files don't work (for example, the Windows install builder files), please update them and move the tag to the version you actually used to build.

The internal version of the sources is 0.2.8_beta1. This is already a good gentoo version. For those systems that don't understand _beta tags, do the following:
Make the VERSION of the package 0.2.8
make the RELEASE tag 0.6.beta1.X
where X can be used to count up different build attempts should they be necessary. Both Debian and RPM support this scheme. The final release will have VERSION 0.2.8.0 and RELEASE 1.

If you already have published a build with VERSION 0.2.8.0 (because that's what the source said), stick to that, but use the RELEASE tag. I think this applies only to the autopackage build by Lucifer.

Don't use --enable-multiver or installation slots; the beta should install exactly as the final release. We're reasonably secure it does not mess things up.

I'll upload the packed source tarball after lunch, and the "generic" RPMs if the build worked.

Edit: uploaded the sources.

I'd like to add that the build filenames should start with armgetronad-(dedicated-)0.2.8_beta1 if possible, so they have an uniform look.

I'll prepare the SF release system, but won't upload anything yet; first, we need to see whether the tagged sources work reasonably well. I think I'll just make everyone a release manager so you can add the completed builds to yourself.

Edit^2: The windows source zip has been updated with the patched config_ide.h.

[Z-Man]

Bugs that will be fixed for the 0.2.8.0:
- anything assigned to someone with priority 5 or higher on the SF bug tracker. There are only seven left at the time of this writing.

Bugs we hope to get more information on (recordings!) by the beta:
- Walls coming off at odd angles in a network game
- Holes blown by explosions not correct on client
- "top kill" number not updated

New bugs found in the beta process:
Resource filenames may be incorrect; the file extension is currently .map.xml, but previously we decided it should be .aamap.xml. (fixed in CVS)
The Windows dedicated installer includes the SDL libraries and libpng/libjpeg. (fixed in CVS)
The ChangeLog did not get generated. (fixed in CVS)
The RPMs require libxml2-2.6.12 or higher, but don't say so in the their dependency list. (fixed in CVS)
The OSX buid crashed when quitting a local game.

What do we do with this one?
cycle accelerates when sitting on wall
I say it's not a bug and we should close it. (Done)

[Z-Man]

Some test RPM builds:

Edit: small patch Windows builders need to apply: open up config_ide.h and change the version definition in the last line to

Code: Select all

#define VERSION "0.2.8_beta1"

[dlh]

Where have major_version and minor_version gone, shouldn't they take the place of manually editing config.h?

[Z-Man]

They're gone from the tarball because there, the version is hardcoded into configure.ac and configure. Sorry, I did not know the mac build depended on them. Probably "make dist" also forgot the mac build files, right? I guess it'll be best if you do the mac build from the tagged CVS sources, then. For the future, we can make it so that the mac build files in the tarball are adapted to the correct versions as well (we'll already have to do that for the Windows files or I'll forget to adapt them again the next release).
In case you have not yet adapted the build environment to the automatic sorting of the resources, copy them over from the tarball.

Edit: I forgot: the script that generates the version has been updated to not add the dot between major and minor version, that will now reside inside the files. For the trunk, we'll revise the scheme even more, because the only reason for the separation into minor and major version was that I let the minor version count up automatically at releases, which simply is not worth the trouble.

Hmm. I have two healthy windows builds here. I'll upload them directly to SF.
Edit: Uploaded them. They're at
http://prdownloads.sourceforge.net/arma ... e?download
http://prdownloads.sourceforge.net/arma ... e?download
And of course not yet listed on the project page and not yet on all mirrors.

[dlh]

They're gone from the tarball because there, the version is hardcoded into configure.ac and configure. Sorry, I did not know the mac build depended on them. Probably "make dist" also forgot the mac build files, right? I guess it'll be best if you do the mac build from the tagged CVS sources, then. For the future, we can make it so that the mac build files in the tarball are adapted to the correct versions as well (we'll already have to do that for the Windows files or I'll forget to adapt them again the next release).
In case you have not yet adapted the build environment to the automatic sorting of the resources, copy them over from the tarball.

Yes, MacOS/ is missing too. I have already corrected the Mac builds to sort the resources (last night, right before the branch).

Edit: I forgot: the script that generates the version has been updated to not add the dot between major and minor version, that will now reside inside the files. For the trunk, we'll revise the scheme even more, because the only reason for the separation into minor and major version was that I let the minor version count up automatically at releases, which simply is not worth the trouble.

Alright, so just major_version + minor_version now. Should I tar up my sources for distribution (er, maybe armagetronad-macosx-0.2.8_beta1.tar.bz2). Zip is not really windows specific, so it may be necessary to state that it is modified sources for windows.

[Z-Man]

Alright, so just major_version + minor_version now. Should I tar up my sources for distribution (er, maybe armagetronad-macosx-0.2.8_beta1.tar.bz2).

Yes, please call it armagetronad-0.2.8_beta1.macosx.tar.bz2. I just invented the convention that all files should be named packagename-version.whatever and want to see how far we get with that. I hope we can build the final version from one tarball.

Zip is not really windows specific, so it may be necessary to state that it is modified sources for windows.

Good point. I'll rename the file to armagetronad-0.2.8_beta1.windows.zip before uploading it to SF.
Mmm. We need a way to differentiate clearly between source and binary distribution files; adding -src to all sources is impractical because the Unix convention is not to do that. Perhaps we should give binary files the exact architecture in the suffix, like armagetronad-0.2.8_beta1.win32.exe?

[TiTnAsS]

This may sound stupid.. .but whats the dif from dedicated and nondedicated -_-....

[Z-Man]

armagetronad-dedicated is the server, armagetronad the client. It's the traditional naming scheme. It may seem like armagetronad-server/armagetronad-client would be better, but the client can act as a server, too, so this would be severly misleading.

[Swampy]

Are we supposed to post any issues we have in this thread, or is there a more appropriate place for our findings to be logged?

I did the install on a Windows 2000 Professional machine and it seemed to go in clean. I tweaked the configs so that I could bring it up as a Swampland beta server, and proceeded to run the dedicated server.

A DOS window opens and then an error dialog pops up on the screen immediately after executing the exe (via the desktop shortcut):
-----------------------------------------------
Program Error
armagetronad_de.exe has generated errors and will be closed by Windows. You will need to restart the program.

An error log is being created.

-----------------------------------------------

I did a search of the system for *.log and found that drwatson.log contained some information that might help track down the problem. I copied and pasted the most recent entry into a txt doc, and attached it here.

The same system also has 2.7.0 installed, and that runs clean, even while having 2.8 installed at the same time.

[TiTnAsS]

Err, i installed it on my D drive program files..and the config files and armagetron ad file are nowhere to be found..but it is under start menu uninstall etc....

EDIT: im on windows....

[Z-Man]

Swampy: Yes, this is one of the right places. The error log shows the exact crash location in a disassembed piece of code for those who don't want to unzip it. Does anyone know how to analyze such a thing without going crazy?

could you attach the settings you ran it with, and tell us what you did with the server? (Connect one or several clients...) Perhaps the problem is easily reproducible in debug mode. We may have to ask you to repeat what you did with a debug build to get better output from the doctor if that does not work.

[Z-Man]

TnA: And when you click on the start menu entry, what happens?

The user specific configuration files (user.cfg) are now stored in your applications settings directory in the .armagetronad folder. I always forget what it's called by default.

[Swampy]

Swampy: could you attach the settings you ran it with, and tell us what you did with the server? (Connect one or several clients...) Perhaps the problem is easily reproducible in debug mode. We may have to ask you to repeat what you did with a debug build to get better output from the doctor if that does not work.

I transferred the numerical values of my 2.7.1 server over into the beta versions setting. I did this by going through line by line and modifying them to match my live server's settings.

I double clicked the dedicated icon on the desktop and it blew up right away. I was never able to actually host at all. It's reproducible every time I try and launch it.

I think it's important to note that the error says "armagetronad_de.exe", but there's no file on my system by that name. I'm going to guess that it's being called by something in armagetronad_dedicated.exe some how.

[Lucifer]

Reinstall, swampy?

The dedicated server now has some extra files it supports. In the same directory you find settings_dedicated.cfg, create two new files, server_info.cfg and settings_custom.cfg.

Put what you need in there. server_info should contain the naim of the server, connection settings, politics, and so forth. Message of the day. You kow. settings_custom is a file you should be able to send to anyone when they ask for Swampland settings.

I don't think this is well documented anywhere right now, but I"ll make sure it gets put somewhere before the final release.