0.2.8 (beta 3 tagged)

[Z-Man]

Just a reminder (already was mentioned in this thread), network version number needs to be bumped. It is reporting pre_0.2.5 right now.

Indeed, anyone know what's causing it?

Yep, that's me forgetting to initialize the corresponding member so the recipient of the server info message thinks the release version is not sent at all, therefore it must be a very old release. It's fixed.

[Tank Program]

Just a reminder (already was mentioned in this thread), network version number needs to be bumped. It is reporting pre_0.2.5 right now.

Indeed, anyone know what's causing it?

Yep, that's me forgetting to initialize the corresponding member so the recipient of the server info message thinks the release version is not sent at all, therefore it must be a very old release. It's fixed.

Darn, I just noticed it while looking at the master server stuff...

[Newk]

almost a year ago i posted a question about the soundeffects and their files in a topic here... nobody came up with an answer, so i guess the sound for grinding is in the code or something... if this is the case it would be nice if this becomes changeable (even with loop-points wich enable you to have a release on the sound?) in the next version.... this is the only sound that cannot be changed yet

[Z-Man]

Newk: Your observations about the files are correct, but there's no chance of getting them configurable for the upcoming release. See, none of the other data changes are really supported by the game since a lot of things are hardcoded and need to be hardcoded. We need proper engine support for these kinds of resources first. Maybe in 0.3.0.

So, there's nothing stopping me from doing the branch next Monday, right? And schedule the first beta release for the weekend around the 15th? I'm away the weekend before that, so I won't be able to do the rather tedious release process. Well, on the other hand, it does not have to be me doing all the work, the snapshot releases on AABeta seem to manage themselves quite nicely without me. So if one of you wants to press the red button, you're welcome to do so.

Proposed branch name: b0_2_8. Keep it simple, no codename. The CVS tags need to be useful for years, and if I want to check out the code that went into 0.2.8.0, I don't want to have to look up its codename first. Objections to that?

I'll be merging the bugfixes in the branch back into the trunk in regular intervals (and mark the merge point in the branch so CVS does not try to merge the same change twice), so ALL bugfixes should be done in the branch once it's there. Unless, of course, the bug is new in the trunk.

I'll update the docs this weekend and see if I can write something about how a proper Windows build with real docs and no AI named @progtilte@ is supposed to be made (A Unix box is still required for that at the beginning, sorry).

[Tank Program]

Sounds like a plan.

[k]

I'll update the docs this weekend and see if I can write something about how a proper Windows build with real docs and no AI named @progtilte@ is supposed to be made (A Unix box is still required for that at the beginning, sorry).

I already have a batch file written that pulls all the code from CVS, builds the client and server, creates the client and server install folders, builds the documentation, creates the installers, and ftps them to a server. It uses several Windows ports of Unix utils (sed, m4, etc) and does the @progtitle@ substitutions (though I just noticed I missed the @progtitle@ in the html docs). The only issue I found with the html doc generation is the date that m4 inserts. Since m4 calls the OS date command in Windows you get "Last modification: The current date is: Fri 07/29/2005 Enter the new date: (mm-dd-yy)". I haven't spent any time fixing this, but I can probably do a replacement of the date before running it through m4. I'll clean it up and post it in the next few days if anyone is interested.

[Luke-Jr]

So, there's nothing stopping me from doing the branch next Monday, right? And schedule the first beta release for the weekend around the 15th?

We've been using CVS snapshots as betas for a while.... we can just get a few people using them to verify the latest versions and move to RCs, probably.

Edit: Also, the site is currently working at http://beta.armagetronad.net/ so we don't need to worry about people being scared off for "unofficialness" anymore.

I'm away the weekend before that, so I won't be able to do the rather tedious release process. Well, on the other hand, it does not have to be me doing all the work, the snapshot releases on AABeta seem to manage themselves quite nicely without me. So if one of you wants to press the red button, you're welcome to do so.

I can probably handle it, if nobody else wants to... We could simply modify aabeta to actually list RCs as such instead of dates running up to a release. The one issue is that currently, aabeta releases are made at arbitrary times... all RCs should be from the same time, preferably.

Proposed branch name: b0_2_8. Keep it simple, no codename. The CVS tags need to be useful for years, and if I want to check out the code that went into 0.2.8.0, I don't want to have to look up its codename first. Objections to that?

Why the 'b'? Then, tag 0_2_8_RC1, 0_2_8_RC2, etc, 0_2_8_0, etc

I'll update the docs this weekend

If possible, verify that it is very clear to map designers their map filepaths MUST (bold, huge font, whatever):
- be unique!!!
- be categorized
- unless otherwise official "permission" is granted (for now), be "AuthorName/MapName-Version.xml" or "ClanName/MapName-Version.xml"

[Z-Man]

K: sounds cool, could you make it public? With support for fetching a tagged version from CVS? Or alternatively taking a source tarball? I think a fully Windows based build process would benefit the workflow, even if some GNU tools are required.
We can scrap the date tag completely; it's not really giving the date of the last change anyway.

We've been using CVS snapshots as betas for a while.... we can just get a few people using them to verify the latest versions and move to RCs, probably.

Edit: Also, the site is currently working at http://beta.armagetronad.net/ so we don't need to worry about people being scared off for "unofficialness" anymore.

Yes, but there is a crucial difference between the beta/RC we're going to release and the recent snapshots and you already spotted it: The snapshots are from random files from CVS without telling the other devs they are made, whereas real releases are either built from tagged versions from CVS or source snapshots. So it's quite possible something stupid I do gets incorporated in one of those snapshots because I only correct it the next day. That's what makes the snapshots inofficial, not their location.

I can probably handle it, if nobody else wants to... We could simply modify aabeta to actually list RCs as such instead of dates running up to a release. The one issue is that currently, aabeta releases are made at arbitrary times... all RCs should be from the same time, preferably.

Sure, why not. Do you think the server can handle the load? Isn't it the same box that choked on your avatar?
And yep, making sure all builds are from the same sources is where the to-be-documented release process kicks in. That's the work of the release manager. Check out current CVS, make basic tests, create source archives, push them to the builders of the versions for other OSes, and if their basic tests run fine: tag, build and distribute.

Why the 'b'?

CVS tag and branch names have to start with a letter, and b nicely signifies it's a branch. Releases can be tagged r0_2_8_0(X). It's the simplest thing CVS allows.

If possible, verify that it is very clear to map designers their map filepaths MUST (bold, huge font, whatever):
- be unique!!!
- be categorized
- unless otherwise official "permission" is granted (for now), be "AuthorName/MapName-Version.xml" or "ClanName/MapName-Version.xml"

Philippe, got that? I'll also put a reminder for it in the section explaining the map settings to users, since server admins can really mess that scheme up.

[Luke-Jr]

K: sounds cool, could you make it public? With support for fetching a tagged version from CVS? Or alternatively taking a source tarball? I think a fully Windows based build process would benefit the workflow, even if some GNU tools are required.

It would be nice to get nightly OSX/etc builds too

We can scrap the date tag completely; it's not really giving the date of the last change anyway.

It should...

We've been using CVS snapshots as betas for a while.... we can just get a few people using them to verify the latest versions and move to RCs, probably.

Edit: Also, the site is currently working at http://beta.armagetronad.net/ so we don't need to worry about people being scared off for "unofficialness" anymore.

Yes, but there is a crucial difference between the beta/RC we're going to release and the recent snapshots and you already spotted it: The snapshots are from random files from CVS without telling the other devs they are made, whereas real releases are either built from tagged versions from CVS or source snapshots. So it's quite possible something stupid I do gets incorporated in one of those snapshots because I only correct it the next day. That's what makes the snapshots inofficial, not their location.

Except that they are official... I can simply add a "branch" field to the list-- no matter when a snapshot is taken from a release branch, it should be OK.

I can probably handle it, if nobody else wants to... We could simply modify aabeta to actually list RCs as such instead of dates running up to a release. The one issue is that currently, aabeta releases are made at arbitrary times... all RCs should be from the same time, preferably.

Sure, why not. Do you think the server can handle the load? Isn't it the same box that choked on your avatar?

It didn't choke... besides, the actual downloading supports mirroring. There's one rsync'd mirror, ATM.

And yep, making sure all builds are from the same sources is where the to-be-documented release process kicks in. That's the work of the release manager. Check out current CVS, make basic tests, create source archives, push them to the builders of the versions for other OSes, and if their basic tests run fine: tag, build and distribute.

I can pick some fixed CVS position and post it on aabeta as source-- then the packages could be notified to get it from there and build.
But one thing I'm pondering is should we have "beta X" or "RC X"? Why not simply "0.2.8 RC 2005-07-30"? There should be no risky/breaking in the 0.2.8 branch, after all...

Why the 'b'?

CVS tag and branch names have to start with a letter, and b nicely signifies it's a branch. Releases can be tagged r0_2_8_0(X). It's the simplest thing CVS allows.

Ah, didn't know the alphabetic requirement-- thought you were implying 'beta'

If possible, verify that it is very clear to map designers their map filepaths MUST (bold, huge font, whatever):
- be unique!!!
- be categorized
- unless otherwise official "permission" is granted (for now), be "AuthorName/MapName-Version.xml" or "ClanName/MapName-Version.xml"

Philippe, got that? I'll also put a reminder for it in the section explaining the map settings to users, since server admins can really mess that scheme up.

Can and have, from what I have seen. It really needs stressing.

[Luke-Jr]

IMHO, before we fork we need to get the icon stuff sorted out. Why should there be a separate icon for OS X?

[Z-Man]

We can scrap the date tag completely; it's not really giving the date of the last change anyway.

It should...

Yeah, but it's almost impossible to automate it correctly. You want the date tag to change when the main file itself is updated, and that's fine. But the main file includes other files, for example the navigation bars and the signature itself. Do you want to update the tag when those change? I think not. But if the main files includes another important file, like AUTHORS, you'd want the tag to update on changes in that file.
Anyway, I now use the approach that the make system defines CHANGEDATE when compiling the doc files. It currently uses the last change date of the main file only, which is good for most pages. And it should be easy to fill in dummy data or even real data for the Windows build.

Except that they are official... I can simply add a "branch" field to the list-- no matter when a snapshot is taken from a release branch, it should be OK.

For me, there are these criteria when a build counts as an official release:
1. the other developers need to be informed that a build is done
2. there is a minimal QA process
3. source code is released
4. optional, but helps: builds for several architectures are done from the same source
5. WE feel somewhat responsible for it. Nothing a single developer pulls out of CVS at any odd time, even if its from a release branch, can qualify here.
6. There are release announcements

Well, the usual shapshots fail all of this. Except K's nightly builds that pass 1. in some sense

3. would actually be required for all builds, the GPL wants the source to be available in the same form as the binary. Having CVS available does not count if you interpret that strictly.

However, building regular snapshots from the release branch still is an excellent idea. Yes, they should be reasonably safe, but I already know that whatever I do against phasing, the fist attempt will break something else that will only be noticed after some days. Therefore, there should be at least one REAL beta release we publish over SourceForge and announce properly. Better two, one to get all our new features out for wide testing and one almost-surely-free-of-really-nasty-bugs one before the real relase; that last one can be called RC.

I can pick some fixed CVS position and post it on aabeta as source-- then the packages could be notified to get it from there and build.

Yep, that would work.

But one thing I'm pondering is should we have "beta X" or "RC X"? Why not simply "0.2.8 RC 2005-07-30"? There should be no risky/breaking in the 0.2.8 branch, after all...

Usually, a RC really is a release candidate: something you can take and rename and it passes for a release. Of course, we'll have to recompile and repack things anyway unless the RC's are already compiled and packed with VERSION=0.2.8.0, but a RC should have a real chance of becoming the final release. So, intermediate versions, even taken from the branch, should be betas. People were complaining that we had 8 RC's the last time
Just date tagging all betas in the usual way sounds fine.

Whoops, small problem: Gentoo version rules say that alpha < beta < pre < rc, and that makes sense. Does anyone know how RPM and APT sort this? If the other distros handle it the same way, we have no choice but to keep calling the versions from the branch pre and switch to rc later.
For the future, I'd suggest this scheme:
- everything from the trunk of CVS is alpha
- random snapshots from a release branch are beta
- planned releases from a release branch are pre (or beta, depending on judgement of the developments)
- the actual release files are first renamed to RC (the internal version is already the official one) and distributed for testing; if they pass, the files are just renamed and redistributed.
Opinions?

[Luke-Jr]

We can scrap the date tag completely; it's not really giving the date of the last change anyway.

It should...

Yeah, but it's almost impossible to automate it correctly. You want the date tag to change when the main file itself is updated, and that's fine.

Eh... now I'm not sure we're even talking about the same things. I'm referring to the date in snapshot versions... eg 0.2.8.pre20050730-- which should be CVS from that date.

Except that they are official... I can simply add a "branch" field to the list-- no matter when a snapshot is taken from a release branch, it should be OK.

For me, there are these criteria when a build counts as an official release:
1. the other developers need to be informed that a build is done
2. there is a minimal QA process
3. source code is released
4. optional, but helps: builds for several architectures are done from the same source
5. WE feel somewhat responsible for it. Nothing a single developer pulls out of CVS at any odd time, even if its from a release branch, can qualify here.
6. There are release announcements

That describes an organised release to me... "official" deals with who does it or how formally it is presented. I'd toss #6 into "final release".

Well, the usual shapshots fail all of this. Except K's nightly builds that pass 1. in some sense

3. would actually be required for all builds, the GPL wants the source to be available in the same form as the binary. Having CVS available does not count if you interpret that strictly.

CVS provides source for all snapshot-type builds. There is no reason why it does not count.

However, building regular snapshots from the release branch still is an excellent idea. Yes, they should be reasonably safe, but I already know that whatever I do against phasing, the fist attempt will break something else that will only be noticed after some days. Therefore, there should be at least one REAL beta release we publish over SourceForge and announce properly. Better two, one to get all our new features out for wide testing and one almost-surely-free-of-really-nasty-bugs one before the real relase; that last one can be called RC.

The snapshots are already in wide testing.

I can pick some fixed CVS position and post it on aabeta as source-- then the packages could be notified to get it from there and build.

Yep, that would work.

beta.aa.net now supports branches. (PS: any suggestions for a layperson term instead of HEAD?)

But one thing I'm pondering is should we have "beta X" or "RC X"? Why not simply "0.2.8 RC 2005-07-30"? There should be no risky/breaking in the 0.2.8 branch, after all...

Usually, a RC really is a release candidate: something you can take and rename and it passes for a release. Of course, we'll have to recompile and repack things anyway unless the RC's are already compiled and packed with VERSION=0.2.8.0, but a RC should have a real chance of becoming the final release. So, intermediate versions, even taken from the branch, should be betas. People were complaining that we had 8 RC's the last time
Just date tagging all betas in the usual way sounds fine.

True, but there's more meaning to a dated RC, IMHO... and if it works good, then there's no need for more than one.

Whoops, small problem: Gentoo version rules say that alpha < beta < pre < rc, and that makes sense. Does anyone know how RPM and APT sort this? If the other distros handle it the same way, we have no choice but to keep calling the versions from the branch pre and switch to rc later.

So "RC" is at least set...

For the future, I'd suggest this scheme:
- everything from the trunk of CVS is alpha
- random snapshots from a release branch are beta
- planned releases from a release branch are pre (or beta, depending on judgement of the developments)
- the actual release files are first renamed to RC (the internal version is already the official one) and distributed for testing; if they pass, the files are just renamed and redistributed.
Opinions?

Don't we have compiled code with the version? We don't want a RC to claim it's a final... Other than that, sounds good.

[Lucifer]

I always thought it went like this:

Alphas are essentially proof-of-concept, or snapshots of work in progress.

Betas are formal releases from a specific date where the purpose is to engage a larger community for finding bugs. Betas are feature-complete. For each platform, the same source is used to compile the beta.

Release Candidate is a dress rehearsal, basically. For a release candidate you do all the same stuff you'd do for a release, except some of the PR stuff, maybe (this varies from project to project). But a release candidate should have no known bugs, should be feature complete, and should have everything the final release will have. If a release candidate goes a certain amount of time without bugs being found, then it becomes the release, with no changes whatsoever. (Excepting as needed to remove the RC-versioning and replace it with the final release version)

The snapshots we've been releasing have been nice, and I think people have really enjoyed having them, but we need to do something a bit more formal even for a beta. If we don't use the same source for a beta release for each platform, then what do we do when someone says "The OS X version has this problem"? How do we know which other platforms may be affected? We can't just ask other players, we have to go to the source. On the other hand, if the betas are clearly marked and each platform is compiled from the same source, then someone says "THe OS X version has this problem" and we can each fire up the game and see if the Mandriva/Gentoo/Generic LInux/Windows builds all suffer the same problem, without going to the source. That's just a contrived example to show the point.

Anyways, I hope this was more coherent than it felt writing, I need to wake up some.

[Z-Man]

Eh... now I'm not sure we're even talking about the same things. I'm referring to the date in snapshot versions... eg 0.2.8.pre20050730-- which should be CVS from that date.

No, we're not . I was referring to the date tags ("Last Change:xxx") at the bottom of the documentation files K had problem with. The versioning timestap works fine.

Alright, so we should have at least one ORGANIZED beta release. Two because the first one will have known problems. Phasing, for example. BTW, I really could use a recording of that.

3. would actually be required for all builds, the GPL wants the source to be available in the same form as the binary. Having CVS available does not count if you interpret that strictly.

CVS provides source for all snapshot-type builds. There is no reason why it does not count.

Try getting the exact source of a snapshot made a week ago. Sure, CVS can give you the rough source at that day, but you don't know when exactly the builder checked out the sources, so you can't be sure whether you miss a change or have one too many. Plus, there's the bug report problem Lucifer points out. It's not all that contrieved, we already have two bug reports for snapshots I don't really know how to handle properly.

beta.aa.net now supports branches. (PS: any suggestions for a layperson term instead of HEAD?)

Cool. Hmm, Minefield? Latest? Anyway, I think the branch selection could use a bit of explanation.

About RCs:

Don't we have compiled code with the version? We don't want a RC to claim it's a final... Other than that, sounds good.

Yes, we have two options there:
- Compile version 0.2.8.0_RC1 into the game. Keep the source of the RC (well, we do that anyway). Later, if the RC should become the release, change the version to 0.2.8.0 and rebuild.
- Compile version 0.2.8.0 directly into the game. Rename the packed builds to 0.2.8.0-RC1. When the RC is found to be good, rename the builds.

The first option has the advantage that the RC is a normal consistent build. The second option has the advantage that less can go wrong when a RC is made official. To me, the first option indeed sounds a bit better. The Unix build process is completely automated, and the Windows build too if K publishes his script, so the risk of something going wrong on the second build are minimal.

Lucifer: sounded coherent enough to me. I'd like to see RCs that way too, but the web begs to differ:
http://www.answers.com/topic/release-candidate?method=8

Anyway, I don't want to call any version RC that has known priority 6 or higher bugs. Remember that the goal for a release was to have no priority 5 or higher bugs left. Of course, we can reach that goal by repriorizing some of the bugs

Luke, about delaying the branch because of the icon: You're not serious about this, are you???? I'ts just the Icon! Besides, any changes to that can as well be made in the branch. The main purpose of the branch is to allow dirty development to continue on the trunk, not necessarily to only allow bugfixes on the branch.

[dlh]

IMHO, before we fork we need to get the icon stuff sorted out. Why should there be a separate icon for OS X?

It had to be changed because the old one used an image from the movie (which was also a different icon from the rest of the project). And since its a mac it needs to Think Different (tm).

About the beta builds: I could make a cron job that does the builds pretty easily. "xcodebuild Armagetron.xcodeproj" and then package it up and send it off (it probably can't layout the icons in the dmg though see attached). Nightly sounds too often, how much really changes in a day? How about weekly?