0.2.8_beta4: release process and bugs
-
- Match Winner
- Posts: 641
- Joined: Sun Jul 10, 2005 9:14 am
I'll try, but really everything you need to know is that the version is stored in the variable VERSION and builds should go to UPLOAD. Well, they don't even need to if you want to push them to aabeta or sf by hand.klax wrote:z-man: Could you explain me how the version is get with the generic build?
The $(VERSIONTAG) target is responsible for setting VERSION, resp. for creating the file builds/.versionfile that contains the version and is included by the makefile. All it does for this is scan the contents of the tarballs directory for tarballs, take the latest one, and sed the version part out of it. It should work if you don't check out the armagetronad module besides the release module if you just drop a source tarball into tarballs.
If the armagetronad module is present, the $(SOURCETAG) target above $(VERSIONTAG) is responsible for creating a tarball. With the help of the copysrc script (the name is misleading, its function evolved from copying the sources), it does the "make dist" procedure (create empty directory, go there, call configure, do make dist) and moves the result in the tarballs directory.
The nasty part about all this is that make does not notice when files it is including are changed. That's why you get the "please rerun make" message. It required some hackery so you only get it once...
I guess that was a brainfart. It is supposed to manage consecutive builds automatically and set the build number on RPMs, for example. But I never used it myself, so we should probably remove it and do everything directly in builds/bVERSION. I would not cry a tear.klax wrote:And also why there is always a RCx subdir?
No, this would be an abuse in my eyes. The epoch is for earth-shattering events, for example if you switch from date-tagged versions to version numbers. Naturally, your versions get smaller, so you have to increase the epoch ONCE to work around it.Walking Tree wrote:I'd say this is the kind of problem epochs are made for.
Lucifer had dug up a document describing the intricate works of debian versions, I'll try to find it. There was something similar to the rpm release tag hackery we're using against the same problem.
Edit: found it. Here's the link:
http://www.debian.org/doc/debian-policy ... -f-Version
the debian_revision seems like the tool of choice. In the automated build, use ${COREVERSION} as upstream_version and ${RELEASETAG} as debian_revision. ${RELEASETAG} is constructed so that it increases in all sensible sorting schemes (even plain alphabetic with 0<1<2...) from alpha versions over betas and release candidates to the final release.
BugFix Windows
Added to config_common.h:
I hate all those functions/methods without a standard
The other bug fix for:
Compiles fine... I'll attach a lag recording later... got quite some lag with 40msec connection
Code: Select all
#define strcasecmp strcmpi
The other bug fix for:
VC++ 7.1 Compiler wrote: "\project\armagetronad\armagetronad\src\engine\ePlayer.cpp(2887) : error C2593: 'operator &&' is ambiguous
could be 'built-in C++ operator&&(eTeam *, eTeam *)'
or 'built-in C++ operator&&(eTeam *, bool)'
or 'built-in C++ operator&&(bool, eTeam *)'
or 'built-in C++ operator&&(bool, bool)'
while trying to match the argument list '(tControlledPTR<T>, tControlledPTR<T>)' with [T=eTeam] and [T=eTeam]
Code: Select all
// register me in the given team (callable on the server)
void ePlayerNetID::SetTeam( eTeam* newTeam )
{
//...
SetTeamForce( newTeam );
// announce the change
if ( bool(nextTeam) && bool(currentTeam) )
{
//...
}
}
Last edited by joda.bot on Sun Dec 04, 2005 4:17 am, edited 1 time in total.
Lucifer: yes, I get three of them. They come from various library settings we adopt from "XXX-config --libs". We could filter the redundant ones out, but the order of libraries is important and I don't want to mess things up.
Joda: fixed, thanks.
If the lag you're talking about was on the Fortress, don't bother. We have some network trouble at the institute sometimes, and that does not affect the displayed ping immediately.
Joda: fixed, thanks.
If the lag you're talking about was on the Fortress, don't bother. We have some network trouble at the institute sometimes, and that does not affect the displayed ping immediately.
Just in case the forum goes down before I can post this: I'm going to push up an after-beta release again, 0.2.8_beta4.2, today or tomorrow. It'll fix the voting bug, the crashes in Windows, and I guess I made the gcc build work on Windows 98. This is not going to be an "official" build, so don't rush building it for all platforms.
Done it. Beta4.2 builds for the usual platforms (Linux 32/64 bit, Windows) are available on Sourceforge and aabeta.
The VC8 build of the client does not work for Windows XP, and all it gives is the cryptic "Installation problem, please reinstall" message. Does anyone know what's up with that or where we may get more information on that?
The VC8 build of the client does not work for Windows XP, and all it gives is the cryptic "Installation problem, please reinstall" message. Does anyone know what's up with that or where we may get more information on that?
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: luke@dashjr.org
@luke: I'm sure it was more or less a typo by z-man(?). z-man really takes his time to fix and answer to problems, so let's just help him out as good as we can ? Just try to say something like "Hey, z-man, I just noticed that the version string is wrong. I guess it's just a typo." that is way better than
"can certain people" as you really know who has to be addressed.
@z-man: Sorry, if ur not the receiving end, then I got it all wrong
"can certain people" as you really know who has to be addressed.
@z-man: Sorry, if ur not the receiving end, then I got it all wrong