0.2.8 (beta 3 tagged)

[Luke-Jr]

Then, when z-man is ready with recording, we can branch and release the first beta, right? I mean, we don't need z-man's top priority bugs fixed to release a formal beta, because we do have all this other code that needs some testing too....

Should 'formal' betas be listed with dates along with the CVS snapshots or should we set the date field to "0280 beta 1" or a mix of both? Perhaps "0280 beta 1<br />YYYY-MM-DD"?

I think the schema should be this:

CVS snapshot: just like it is, it's fine

beta: armagetronad-0.2.8.0.beta1 (or beta-1).whatevertheappropriateextension

Release candidate: armagetronad-0.2.8.0.rc1.whatevertheappropriateextension

Final version: armagetronad-0.2.8.0.whatevertheextension

Those tell you nothing about the OS, architecture, or bitlengh.

We also have other code besides those bugs, new code, that needs to be tested at large. I'd like to see how well the headlights work out for real, so far Jonathan's the only one who has pretty headlights.

Headlights are not targetting 0.2.8 or 0.3, last I checked... they wouldn't make a formal beta either, obviously.

I've no idea how wide the testing on shaped arenas has been.

There's been a lot of people who tried it... Not enough servers for such people to play on, though.

I figure we'll be in beta state for about a month, maybe two. I'm not actually a big fan of doing release candidates and I'd just as soon go straight from last beta to official release.

Perhaps calling these RCs instead of betas is a better idea, since we're using the word "beta" to refer to CVS snapshots already.

A release with the recording code would be useful, but it seems users already have a hard time differentiating between official/beta/totally unoffical cvs builds.

I've never seen any unofficial CVS builds... by definition, a CVS build is a CVS build and is always 'official' so long as the code is unmodified after coming from the CVS server. AA CVS snapshots have been referred to as "beta" to allow ordinary users to understand the risk better and still use them.

I think if we do release a offical beta,

A better term is "formal beta" or "RC"

we should only do it here on the forums and not on sourceforge.

No reason RCs can't be listed on aabeta... IMHO, it should be either aabeta or SF, since those are really the only proper release locations.

That way we only get seasoned tron'ers testing it out, and not someone who just downloaded the game and it is their first time playing.

A good reason to choose the aabeta path.

[Lucifer]

Those tell you nothing about the OS, architecture, or bitlengh.

Let's see, if it says ".exe" then it's a Windows binary. If it says ".dmg" then it's a Mac OS X binary. The Mandriva rpm will have "-##mdk" appended to the version. A distro-neutral rpm shoudl have nothing, an FC rpm should have -#fc#, etc.

If it's a gentoo ebuild, it has another extension. If it's a debian package, yet another.

Builds that are 64bit should be clearly marked, of course, and in a manner that facilitates upgrading with the user's package manager throughout the release process. And rpm automatically puts the architecture in the name anyway, as far as I know so does debian's deal, and an ebuild doesn't matter because you have to buid it for your system anyway, right?

Where's the problem? These are all accepted practices...

Headlights are not targetting 0.2.8 or 0.3, last I checked... they wouldn't make a formal beta either, obviously.

And why not? Because it's not on the roadmap? I played with Jonathan's code because I thought it would be a quick-to-add graphical enhancement that would be nice to have in aardvark. Then we had that little conversation about performance, and I mentioned that if the performance issues were taken care of I'd like to include it for aardvark. So Jonathan went and put some time into it, presumably because he wanted to see it in the release.

Other features not on the roadmap that have been added:

Clock
New remote admin stuff
More?

And they should all be in the release since they're all in "completed" state. (Yeah, the clock could use some extra configuration, and through the beta process it'll probably get resized a bit and some other things, and that's fine, that's what "beta" is for)

I figure we'll be in beta state for about a month, maybe two. I'm not actually a big fan of doing release candidates and I'd just as soon go straight from last beta to official release.

Perhaps calling these RCs instead of betas is a better idea, since we're using the word "beta" to refer to CVS snapshots already.

Perhaps we shouldn't be calling cvs snapshots beta releases, since they aren't beta releases?

A release with the recording code would be useful, but it seems users already have a hard time differentiating between official/beta/totally unoffical cvs builds.

I've never seen any unofficial CVS builds... by definition, a CVS build is a CVS build and is always 'official' so long as the code is unmodified after coming from the CVS server. AA CVS snapshots have been referred to as "beta" to allow ordinary users to understand the risk better and still use them.

By definition an "unofficial build" is a build that is not supported by us, even if it's produced by us. CVS snapshots count, if people have problems with them we're not guaranteed to care about it. Generally we do, of course, because the problems people have with cvs snapshots are things we want to solve, which is probably what the purpose of the snapshot was in the first place. But if it trashes a user's hard drive, too bad, it's not like you weren't warned. An official build is different because we'll support it to some extent. It shouldn't do anything damaging to a person's system, and if it does we have an implied commitment to both care about it and try to fix it in a timely manner.

Moving on to other business , z-man, did you want to test recording a bit before merging it, is that what's going on? Does recording work on clients right now as well or is it server-oriented? Personally, I'd kinda like to branch pretty quickly. If you don't have any reason not to, you could merge it, then we could branch for 0.2.8.0 and release a cvs snapshot right away and ask for some last minute testing preparing for beta, or we could just branch and each of us do our own QA preparing for beta. I'd kinda like to have a beta out by this time next week if at all possible. No hurry or pressure, of course.

[Luke-Jr]

Those tell you nothing about the OS, architecture, or bitlengh.

Let's see, if it says ".exe" then it's a Windows binary.

Not necesarilly (you forget DOS, at least), and even though Windows is the only realistic OS for EXE, what architecture? x86/32? x86/64? Alpha? PowerPC? All those are existing archs Windows either supports or did at one time.

If it says ".dmg" then it's a Mac OS X binary.

DMG is a disk image file-- it could be *any* OS or arch.
Assuming only OS X uses it, you still don't tell me anything about the arch-- PPC/32? PPC/64? x86/32? x86/64? Again, OS X supports at least those four.

The Mandriva rpm will have "-##mdk" appended to the version.

See above about archs, but add to the list Sparc/*, MIPS/*, etc...

A distro-neutral rpm shoudl have nothing,

There is no such thing as a distro-neutral RPM...

If it's a gentoo ebuild, it has another extension.

.ebuild -- this will actually work for any arch

If it's a debian package, yet another.

Still need an arch specified... (.deb)

Builds that are 64bit should be clearly marked, of course, and in a manner that facilitates upgrading with the user's package manager throughout the release process.

64-bit is nothing special. 32-bit should be marked just as well.

And rpm automatically puts the architecture in the name anyway, as far as I know so does debian's deal, and an ebuild doesn't matter because you have to buid it for your system anyway, right?

So your example filename doesn't apply to RPM/Deb, I guess?

Where's the problem? These are all accepted practices...

You were suggesting filenames *without* the OS or arch mentioned. Is there a problem with the naming scheme we've been using for aabeta?

Headlights are not targetting 0.2.8 or 0.3, last I checked... they wouldn't make a formal beta either, obviously.

And why not? Because it's not on the roadmap?

And last I checked, you seconded my feature freeze.

I played with Jonathan's code because I thought it would be a quick-to-add graphical enhancement that would be nice to have in aardvark. Then we had that little conversation about performance, and I mentioned that if the performance issues were taken care of I'd like to include it for aardvark. So Jonathan went and put some time into it, presumably because he wanted to see it in the release.

If it's done in time, I don't have any objections... but since it didn't make the feature freeze, it probably shouldn't delay the release waiting for it.

Other features not on the roadmap that have been added:
Clock

minor, not worth a roadmap mention

New remote admin stuff

??? first I've heard of it?

And they should all be in the release since they're all in "completed" state. (Yeah, the clock could use some extra configuration, and through the beta process it'll probably get resized a bit and some other things, and that's fine, that's what "beta" is for)

That's fine (with me), so long as none of it delays the release.

I figure we'll be in beta state for about a month, maybe two. I'm not actually a big fan of doing release candidates and I'd just as soon go straight from last beta to official release.

Perhaps calling these RCs instead of betas is a better idea, since we're using the word "beta" to refer to CVS snapshots already.

Perhaps we shouldn't be calling cvs snapshots beta releases, since they aren't beta releases?

You want to explain to Joe Player what "CVS snapshot" or even "snapshot" refers to? "That's like a screen shot, right??"-- we went over this in another thread =p

A release with the recording code would be useful, but it seems users already have a hard time differentiating between official/beta/totally unoffical cvs builds.

I've never seen any unofficial CVS builds... by definition, a CVS build is a CVS build and is always 'official' so long as the code is unmodified after coming from the CVS server. AA CVS snapshots have been referred to as "beta" to allow ordinary users to understand the risk better and still use them.

By definition an "unofficial build" is a build that is not supported by us, even if it's produced by us. CVS snapshots count, if people have problems with them we're not guaranteed to care about it. Generally we do, of course, because the problems people have with cvs snapshots are things we want to solve, which is probably what the purpose of the snapshot was in the first place. But if it trashes a user's hard drive, too bad, it's not like you weren't warned.

That's the case with all releases. I'm not aware that anyone is providing a warranty for AA...

An official build is different because we'll support it to some extent.

The same extent we 'support' CVS stuff.

It shouldn't do anything damaging to a person's system, and if it does we have an implied commitment to both care about it and try to fix it in a timely manner.

I'm not against making such an attempt, but if someone loses their hard drive because of some non-beta release, I have no intention of paying for expensive data recovery...

Moving on to other business , z-man, did you want to test recording a bit before merging it, is that what's going on? Does recording work on clients right now as well or is it server-oriented?

Recording works fine here, though it didn't seem to record a crash occurance-- playback exits cleanly.

Personally, I'd kinda like to branch pretty quickly. If you don't have any reason not to, you could merge it, then we could branch for 0.2.8.0 and release a cvs snapshot right away and ask for some last minute testing preparing for beta, or we could just branch and each of us do our own QA preparing for beta. I'd kinda like to have a beta out by this time next week if at all possible. No hurry or pressure, of course.

Can I hurry and pressure? =D

[Jonathan]

Let's see, if it says ".exe" then it's a Windows binary. If it says ".dmg" then it's a Mac OS X binary.

And if it says ".iso" it's a Linux binary?
(that's basically what you're saying about dmgs)

And why not? Because it's not on the roadmap? I played with Jonathan's code because I thought it would be a quick-to-add graphical enhancement that would be nice to have in aardvark. Then we had that little conversation about performance, and I mentioned that if the performance issues were taken care of I'd like to include it for aardvark. So Jonathan went and put some time into it, presumably because he wanted to see it in the release.

Nah... it started out as a way to show a problem with sensors, and we had some fun with it. Then when the thread was revived I went thinking about a way to improve the quality and came up with a fragment program. That also made it possible to reduce the number of sensors (OK, you could have interpolated for lines but the quality would still suck) and made the framerates playable (most of the time I don't notice).

[Lucifer]

I'm not talking about filenames anymore. You're just getting hopelessly pedantic. Like you've never seen an rpm/deb package before or something.... (hint: they all list the arch if it's a binary package)

Headlights are not targetting 0.2.8 or 0.3, last I checked... they wouldn't make a formal beta either, obviously.

And why not? Because it's not on the roadmap?

And last I checked, you seconded my feature freeze.

Didn't we define "feature freeze" as "no new major features"? At least, that's how I've seen it defined on other projects, maybe we just haven't done that here. In any case, I've never seen an open source project refuse to release features that were just little things thrown in after the freeze over a technicality....

If it's done in time, I don't have any objections... but since it didn't make the feature freeze, it probably shouldn't delay the release waiting for it.

*smack* Pay attention, it's done now.

New remote admin stuff

??? first I've heard of it?

Again, pay attention.

You want to explain to Joe Player what "CVS snapshot" or even "snapshot" refers to? "That's like a screen shot, right??"-- we went over this in another thread =p

Sure. Apparently I have a higher opinion of people in general and players of this game specifically than you do.

I'm not against making such an attempt, but if someone loses their hard drive because of some non-beta release, I have no intention of paying for expensive data recovery...

Of course not. I said "implied commitment to care and try to fix it", not "liable for damages". Check out the GPL, our legal liability is spelled out in capital letters there.

[Luke-Jr]

I'm not talking about filenames anymore. You're just getting hopelessly pedantic. Like you've never seen an rpm/deb package before or something.... (hint: they all list the arch if it's a binary package)

Not for a number of years, no, I haven't... (one exception being the Mdk pkg you uploaded, but I didn't analyse its filename...)

And why not? Because it's not on the roadmap?

And last I checked, you seconded my feature freeze.

Didn't we define "feature freeze" as "no new major features"? At least, that's how I've seen it defined on other projects, maybe we just haven't done that here. In any case, I've never seen an open source project refuse to release features that were just little things thrown in after the freeze over a technicality....

I don't consider something to be 'little' if it takes significant days to make it work
As I said, if it doesn't delay the release, I don't care if it's in there... If it would delay, then it's not a small feature/change.

If it's done in time, I don't have any objections... but since it didn't make the feature freeze, it probably shouldn't delay the release waiting for it.

*smack* Pay attention, it's done now.

Then add it. I was merely commenting on how I was unaware it was targetting the release and you take it as an offensive attack against including it...

You want to explain to Joe Player what "CVS snapshot" or even "snapshot" refers to? "That's like a screen shot, right??"-- we went over this in another thread =p

Sure. Apparently I have a higher opinion of people in general and players of this game specifically than you do.

Well, IIRC, you have an account for modifying the site already, so go ahead and do so...

I'm not against making such an attempt, but if someone loses their hard drive because of some non-beta release, I have no intention of paying for expensive data recovery...

Of course not. I said "implied commitment to care and try to fix it", not "liable for damages". Check out the GPL, our legal liability is spelled out in capital letters there.

So if there's a bug in CVS, you don't care to fix it? I don't quite see the difference of 'support' provided...

[Lucifer]

I don't consider something to be 'little' if it takes significant days to make it work
As I said, if it doesn't delay the release, I don't care if it's in there... If it would delay, then it's not a small feature/change.

Heh, you're not taking several things into account and it's probably because you don't know them.

1. I've *never* worked with OpenGL before.
2. I haven't done graphics programming of any kind since 1992. (except for the statsig)
3. I haven't worked in C++ for over a year.
4. I haven't looked at very much of the armagetron code.

Blah, the list goes on. I gained valuable experience making it work, but the fact that it took several days of serious effort had more to do with me than with the feature itself.

Then add it. I was merely commenting on how I was unaware it was targetting the release and you take it as an offensive attack against including it...

I just get tired of telling you the same thing over and over, that's all.

So if there's a bug in CVS, you don't care to fix it? I don't quite see the difference of 'support' provided...

Now you're just being stubborn. I don't see any reason to comment on this. You act like someone who's been around the open source community a lot, and every single project I've been involved with in one form or another has used the same set of definitions and generally taken the same attitude towards cvs snapshots, beta releases, release candidates, and releases, and apparently none of them did it Luke's Way. Pardon me for thinking we had a common frame of reference, I'll try not to make that mistake again.

[Luke-Jr]

I don't consider something to be 'little' if it takes significant days to make it work
As I said, if it doesn't delay the release, I don't care if it's in there... If it would delay, then it's not a small feature/change.

Heh, you're not taking several things into account and it's probably because you don't know them.

1. I've *never* worked with OpenGL before.
2. I haven't done graphics programming of any kind since 1992. (except for the statsig)
3. I haven't worked in C++ for over a year.
4. I haven't looked at very much of the armagetron code.

Blah, the list goes on. I gained valuable experience making it work, but the fact that it took several days of serious effort had more to do with me than with the feature itself.

Okay, so you win there... but would it really been worth delaying a release just to complete that feature?

Then add it. I was merely commenting on how I was unaware it was targetting the release and you take it as an offensive attack against including it...

I just get tired of telling you the same thing over and over, that's all.

Well, sometimes it seems like you don't read my posts... just like how you seem to think I don't read yours

So if there's a bug in CVS, you don't care to fix it? I don't quite see the difference of 'support' provided...

Now you're just being stubborn. I don't see any reason to comment on this. You act like someone who's been around the open source community a lot, and every single project I've been involved with in one form or another has used the same set of definitions and generally taken the same attitude towards cvs snapshots, beta releases, release candidates, and releases, and apparently none of them did it Luke's Way. Pardon me for thinking we had a common frame of reference, I'll try not to make that mistake again.

Eh? My point was that we are taking the same attitude toward snapshots, betas, RCs, and releases... how is that "none of them did it Luke's Way"?? O.o;

[Z-Man]

About merging the recording: Sure, I think it is ready. I want to do a small interface reworking (code testing whether a recording/playback is currently running does not look like it does so, which is very bad). The rest of the problems with recording itself can be handled after the merging.

I'd also vote for calling the "Take CVS as it is today without asking all the devs whether the code is OK" a Snapshot. And I said so in the AABeta thread.

But please, please, stop this little fight. This thread is getting useless...

[Luke-Jr]

About merging the recording: Sure, I think it is ready. I want to do a small interface reworking (code testing whether a recording/playback is currently running does not look like it does so, which is very bad). The rest of the problems with recording itself can be handled after the merging.

BTW, any chance that in playback mode, the keys can be given different meanings? eg:
Left/right arrows jump/go back and forward
Up/down arrows adjust the playback speed
Esc stops playback

[Z-Man]

Replied here:
http://guru3.sytes.net/viewtopic.php?p=26747#26747

[Luke-Jr]

Are these still incomplete?

- Refactoring of network code (z-man)
- Server bookmarks in browser (nemo)
- Dynamically determine available display resolutions (Lucifer)

[Z-Man]

Netcode is done (as can be seen on SF, of course), Windows and Linux code have equal functionality again.
The server bookmarks are there but need a tiny bit of cleanup.

[Luke-Jr]

...bump
How's server bookmarks coming?

[Z-Man]

I admit I got a bit distracted by the automake transition...
It's scheduled as the next non-emergency bugfix thing I do, probably this weekend, but I can't promise anything as I have a talk to prepare for monday.