The road to 0.2.8.2

[Z-Man]

Plan: I'll make a series of alpha snapshots before the first release candidate. Snapshots are far easier to produce, no tagging, no cumbersome SF file release, no announcement, less tests. And the other builders don't have to follow up at all.

So here comes alpha20060414. It's available from AABeta only, and only as autopackage and gcc Windows build. There has likely been a bit of regression, i.e. new bugs have appeared and old ones have snuck back in. For example, the new relocation code doesn't work in Windows yet, the application has to be run with the current directory set to the installation directory. The start menu entries do that, so it's no real problem.

While 0.2.8.0 and 0.2.8.1 were stabilized, quite a lot of small additions have been made towards 0.2.8.2:

Changes since 0.2.8.1:
- Timestamps and teamscores added to scorelog.txt
- Dedicated server now works on FreeBSD and OpenBSD
- User running the dedicated server is called "armagetronad" again, the longer "armagetronad-dedicated" caused problems with BSD
- Test versions refuse to connect to servers more than one version ahead
- Team spawn formation is now configurable
- Added reasons to bans
- Added spectator autokicking
- Added history to chat and console (wrtlprnft)
- You only enter a game once your client is synced
- /msg now prefers exact matches over partial matches
- Cycles now have better memory for pending turns (wrtlprnft)
- Added player join/leave/rename messages to ladderlog.txt with IPs
- Ping variance influence on packet loss tolerance code is now clamped by the regular, configurable, packet loss tolerance: effect of variance can be no bigger than the effect of ping.
Bugfixes:
- After a "perfect" 180, you're more often on the right side of your own wall
(note: that's what Wrtl discovered as phasing and Silly as a new form of bouncing)
- The smart cam did not like fluctuating framerates
- Improved debug recording reliability: multiple master server visits
and too quick keypresses were causing trouble.
- Canonical DESTDIR support and added ROOTDIR support for testing
- Login floods are detected and ignored
- Player name updates sanitized
- Disabled complicated feasibility tests for team menu entries, they did not have the full information and were often wrong
- Team score only added to player score if no teamplay is possible

If you look hard, you'll find the Easter Chicken has left a surprise. Everyone can find it, but only with this build, it will be useful. Happy Holidays, everyone!

[wrtlprnft]

Do you want me to put my TAB completion in b0_2_8? I remember you saying I can if I want, and there's lots of people asking me how they can get it. And it's a very local change
I'd better ask since it uses some std::string suff which should be easy to rewrite to just use the tString functions (of course I'll leave HEAD untouched by that).

[Z-Man]

If you can make that without too much fuzz, certainly.

The egg is a bit spoiled Another good thing about alpha snapshots is that I can just overwrite it with a new build without getting into trouble with the release police, so that's what I'm going to do. Hold that download some minutes, I'll tell you when the fixed version is online.

[wrtlprnft]

How boooooring
Then I can just diff the two alphas and find it...

[Z-Man]

Bet you can't. The fix is somewhere else But you can diff two other things.

[Z-Man]

Ok, the new download is up. I actually didn't overwrite the old version, but stored the new one in a new directory. So don't just refetch your old link, visit aabeta again.

[wrtlprnft]

http://beta.armagetronad.net/fetch.php/ ... rc.tar.bz2

Warning: filemtime(): Stat failed for download/0.2.8/0.2.8_alpha20060414-1/armagetronad-0.2.8_alpha20060414.src.tar.bz2 (errno=2 - No such file or directory) in /var/www/aabeta/htdocs/fetch.php on line 25

Warning: Cannot modify header information - headers already sent by (output started at /var/www/aabeta/htdocs/fetch.php:25) in /var/www/aabeta/htdocs/fetch.php on line 38

[Z-Man]

Looks like I did overwrite the old version after all. Stupid script. Try again, please.

[wrtlprnft]

Ok, works now, thanks

[Luke-Jr]

Do you want me to put my TAB completion in b0_2_8?

That's a feature. 0.2.8 has been feature-frozen for a while.

Another good thing about alpha snapshots is that I can just overwrite it with a new build without getting into trouble with the release police, so that's what I'm going to do.

No! Overwriting bad. Worst case, if you want to do something like this is use a new filename for the replacements and delist the older ones, though I don't see any reason not to keep both listed.

Looks like I did overwrite the old version after all. Stupid script. Try again, please.

Got a backup?

[Z-Man]

Got a backup?

No. Another niche thing about snapshots, only the last one is of relevance.

Care to explain why you think keeping old, known-to-be-broken, versions around when a minimally changed fix is available?

It's going to be at least one month and two more testing versions before 0.2.8.2 is released. Wrtl doesn't have any bugs to fix for it. As far as I can tell, the tab completion code can impossibly break anything but tab completion. There is plenty of time to port and test the feature. All criteria for a backport are fullfilled.

[Luke-Jr]

Got a backup?

No. Another niche thing about snapshots, only the last one is of relevance.

Technically, there shouldn't really be a difference between snapshots of the same date, since they're supposed to be based off midnight that day.

Care to explain why you think keeping old, known-to-be-broken, versions around when a minimally changed fix is available?

Because I'm providing the space and I'm a pack-rat? =p

It's going to be at least one month and two more testing versions before 0.2.8.2 is released. Wrtl doesn't have any bugs to fix for it. As far as I can tell, the tab completion code can impossibly break anything but tab completion. There is plenty of time to port and test the feature. All criteria for a backport are fullfilled.

The criteria for a backport to 0.2.8 has been, since the feature-freeze, that it be a bug fix. Anything that is not fixing a bug does not belong there, that's why it's 0.2.8. If people can't wait for 0.3.0, then someone can always do a 0.3_alpha.
These also should be removed from 0.2.8:
- Added reasons to bans (client-side could be justified, but it's a feature on the server)
- Added spectator autokicking
- Added history to chat and console

I guess we should have considered wanting to do a minor-features-only increment when we decided the version structure? It wouldn't need to be too late, actually. We could still insert a numeral between 'feature-set' and 'bugfix' to get X.Y.Z -> X.Y.N.Z where N is a 'minor-feature-increment'. Thus, we could release a 0.2.9 with minor feature additions to 0.2.8, and once 1.0[.0].0 is released, a 1.0.1.0 would be minor features on top of that.

[Z-Man]

Technically, there shouldn't really be a difference between snapshots of the same date, since they're supposed to be based off midnight that day.

Practically, that's of little use in a branch because CVS doesn't seem allow you to get the contents of a branch at a given date back. And I'd have had to wait one day to publish the fix, which wasn't possible, as I'm off to my parents today and can't to a Windows build there. Perhaps we should, instead of the date restriction, include a snapshot of the various CVS directories at the time of the build? That would allow us to reconstruct the CVS checkout even for skewed snapshots.

Care to explain why you think keeping old, known-to-be-broken, versions around when a minimally changed fix is available?

Because I'm providing the space and I'm a pack-rat? =p

That would have been my first guess Valid. Is the approach of keeping the file names the same, but appending a -<BUILD> to the directory name, all right? That would be easiest to mend into the upload script. Otherwise, we'd have to adapt the version generation script to accept information from the outside. Which isn't such a bad idea anyway, either.

Now this is irrelevant anyway, because wrtl already noticed in IRC that he relies too much on std::string for a backport, but anyway:
The criteria for what goes where are that we want every next version we release to be the best possible version at that given date. Obviously, bugfixes have the highest priority, but I can't see why a developer with free time (because he's not busy with bugfixes) can't implement a small feature that is well isolated so it can't rip open bugs in other parts of the system.

These also should be removed from 0.2.8:
- Added reasons to bans (client-side could be justified, but it's a feature on the server)

That's clearly a social bugfix. The person banned has a right to know why he was banned.

- Added spectator autokicking

DOS bugfix

- Added history to chat and console

Wrtl, as our newest member, didn't have any bugs to fix and wasn't even here before the feature freeze. And it's a nice, small, and often requested feature.

I guess we should have considered wanting to do a minor-features-only increment when we decided the version structure?

You've got a point here, I wouldn't mind making it 0.2.9 instead of 0.2.8.2. We're going to speed up apparent version increases, and we may as well do so gradually. I don't know whether we want long versions like 1.0.2.3 in the end, though. What do the others think?

[Lucifer]

Well, I'm firmly opposed to long version numbers. Most people seem to do alright with 3 digits, but add a fourth and it'll be a struggle to find out what version people are having problems with. Add to that the dyslexia of some of the developers and 4 digit version numbers are just asking for trouble.

Then there's also the argument that says we shouldn't load users with our own organization, whatever it is. Then users feel like they're getting strung up by a bureaucracy instead of getting cool software from cool people.

My only concern here is that there's not a lot of space between 0.2.8 and 0.3, and if 0.3 is the development branch (er, trunk, whatever), then I don't know that we want to burn through 0.2.9 too quickly. A solution is to draw a line at 0.5, make the development branch 0.5 and then we have some wiggle room.

Also, we never decided not to backport stuff to the stable branch. Quite the contrary, we decided on a set of parameters that a backported feature has to satisfy in order to make it. What we've got, then, is that whenever something appears to satisfy those parameters and someone suggests it be backported, Luke shows up and asserts that we can't do it, but near as I can tell, Luke stands alone on that assertion. No sense arguing about it every time it comes up, the argument is always the same.

[Luke-Jr]

Technically, there shouldn't really be a difference between snapshots of the same date, since they're supposed to be based off midnight that day.

Practically, that's of little use in a branch because CVS doesn't seem allow you to get the contents of a branch at a given date back. And I'd have had to wait one day to publish the fix, which wasn't possible, as I'm off to my parents today and can't to a Windows build there. Perhaps we should, instead of the date restriction, include a snapshot of the various CVS directories at the time of the build? That would allow us to reconstruct the CVS checkout even for skewed snapshots.

That works, but I would suggest also including the UTC time in the filename (and maybe in a comment in releases.php)

Care to explain why you think keeping old, known-to-be-broken, versions around when a minimally changed fix is available?

Because I'm providing the space and I'm a pack-rat? =p

That would have been my first guess Valid. Is the approach of keeping the file names the same, but appending a -<BUILD> to the directory name, all right?

Err, no? It defeats the purpose of having directories to restrict them to a single release... How about having the time in the filename?

Now this is irrelevant anyway, because wrtl already noticed in IRC that he relies too much on std::string for a backport, but anyway:
The criteria for what goes where are that we want every next version we release to be the best possible version at that given date. Obviously, bugfixes have the highest priority, but I can't see why a developer with free time (because he's not busy with bugfixes) can't implement a small feature that is well isolated so it can't rip open bugs in other parts of the system.

"every next version we release to be the best possible version" with regard to features is the development releases at odd numbers. Even numbers focus on stabilizing their feature-set. What if someone doesn't want new features, just the bug fixes?

These also should be removed from 0.2.8:
- Added reasons to bans (client-side could be justified, but it's a feature on the server)

That's clearly a social bugfix. The person banned has a right to know why he was banned.

That's disputable... but since some might take that view, it could be considered as a bug fix I guess.

- Added spectator autokicking

DOS bugfix

Oh? How does kicking innocent spectators fix anything? This would keep me from upgrading my server...

- Added history to chat and console

Wrtl, as our newest member, didn't have any bugs to fix and wasn't even here before the feature freeze. And it's a nice, small, and often requested feature.

It's still a feature.

I guess we should have considered wanting to do a minor-features-only increment when we decided the version structure?

You've got a point here, I wouldn't mind making it 0.2.9 instead of 0.2.8.2.

I presume you mean 0.2.9.0... or 0.2.9.2 (keep bugfix revision matching on minor-feature-increments, perhaps?) but either way, we should still put out a 0.2.8.2 with the bug fixes.

We're going to speed up apparent version increases, and we may as well do so gradually. I don't know whether we want long versions like 1.0.2.3 in the end, though. What do the others think?

How else would make sense to show four different version elements? We have a "completeness-factor" (what else is the first digit?) and major revision that make up the base feature-set. It looks like we want a minor-feature-increment subset... and we of course want a bugfix revision.

Well, I'm firmly opposed to long version numbers. Most people seem to do alright with 3 digits, but add a fourth and it'll be a struggle to find out what version people are having problems with. Add to that the dyslexia of some of the developers and 4 digit version numbers are just asking for trouble.

Thus far, our releases have been quad-digit. It's not like players won't be used to it.