Release Date?

[submarine]

Is there any date for the next release?

[LordMatt]

The hope is to release this holiday weekend.

[Tobi]

Actually, I do not think *this* weekend is entirely realistic (I only have tonight and sunday to do spring stuff, and I don't think all others magically fix everything before sunday ), but it really should be in xmas holidays.

[Argh]

I would vote at least one more week, not this weekend. We have a lot of new features, most of which... er... have not been really tested thoroughly.

That, and I'm hoping that maybe the new AirTransport movetype stuff might get done before release

Oh... and before release... I can't emphasize this enough... the documentation in the Changelog needs to improve. I have captured a fair amount of the COB changes in my "STANDARD_COMMANDS" file, which is in PURE, but that's not exactly... documentation... just my own FYI...

[Tobi]

Actually, documentation should not be in the changelog.
Changelog is changelog, not huge random order documentation.

[Auswaschbar]

I would vote at least one more week, not this weekend. We have a lot of new features, most of which... er... have not been really tested thoroughly.

Do you think this will ever change?

[Argh]

Changelog is changelog, not huge random order documentation.

Ok... then, um... do we need to have a new document concept for releases? The last three have been so chock-full of new features, I suspect anybody who wasn't watching SVN would be quite overwhelmed. Moreover, certain things in the COB interpreter need more documentation than a one-liner, for example, here's my documentation for GET PLAY_SOUND (one of the more important things in the next release, imo, although it may take people a minute to realize what this means):

Code: Select all

#define PLAY_SOUND		101	//GET only.  Plays sounds via these instructions:

/*
1) Adds a new get call, PLAY_SOUND, to play a sound that can be heard only by allies, enemy, in los, etc.
2) changes get health to allow a unit ID to be passed
3) adds a call to create() at the end of ReloadCOB

GET PLAY_SOUND(sound number, volume, who hears the sound, where to play the sound)

To set up sounds to use with GET PLAY_SOUND, put a function like this near the top of your bos:
Sounds()
{
play-sound ("movement", 10);
play-sound ("pew", 10);
play-sound ("reporting", 10);
}
The sound number is based on the order the sounds appear, staring from 0. To call the songs by name, add #defines like this:
Sounds()
{
play-sound ("movement", 10);
#define movement 0
play-sound ("pew", 10);
#define pew 1
play-sound ("reporting", 10);
#define reporting 2
}

To actually call the sound, you use a line such as this:
GET PLAY_SOUND (pew, 655360);

1) sound number - as above

2) volume - similar to the volume for play-sound, more affecting the distance where it is audible than actual volume
- given as a float multiplied by 65536

3) who hears the sound
0 = anyone with the unit in ALOS
1 = anyone with the unit in LOS
2 = anyone with the unit in ALOS or radar
3 = anyone with the unit in LOS or radar
4 = everyone
5 = the unit's allies
6 = the unit's team
7 = the unit's enemies

4) where to play the sound
- if 0, the sound is played from the unit's position
- if 1, the sound is played directly from the speakers, the same way unit replies are*/

The changelog, however, says nothing about this commit! That kind of thing is a problem. If nothing else, stuff needs to be documented in Changelog.txt before being committed, imo...

[Tobi]

Multiple structured documents about certain parts of the engine (e.g. COB, LuaUI) would be a better idea yeah.

If nothing else, stuff needs to be documented in Changelog.txt before being committed, imo...

I don't see how that makes sense?

Usually you document something around the same time you code it (most people document after coding, or in Spring, don't document at all), so you can as well commit both implementation, documentation and changelog changes at the same time (which is the best we can get I think.)

[LordMatt]

Tobi what are the specific issues outstanding? This weekend I want to play a bunch of real games with spring SVN (if I can get people to play with me) to find bugs.

[KDR_11k]

Argh, the changelog wasn't updated since that commit (that's the text Lurker wrote BTW, you make it sound like you did). AFAIK Tombom is in charge of that. The commit logs are more up-to-date than the changelog.txt.

[Tobi]

Currently I am thinking about between christmas and new year. (keeping it in 2007 is a nice psychological deadline )

[Tobi]

2007 is not feasible anymore, we need (at least) 1 huge test like yesterday once the bugs found yesterday are ironed out.

I'll organize some testing on tuesday and if that works out fine release on wednesday.

[AF]

I would argue that while we should preferably release with all or most of our bugs gone like we have been doing, we should instead release based on how many bugs there are in comparison to the current stable release.

thus the new release rule would be:

if bugCountSVN < bugcountStable then release

and not

if bugCountSVN == 0 then release

At least that way we have a larger user base to find issues we have more updates and we have a steady level of progress rather than large jumps every 5-6 months followed by 1 or 2 minor fix releases.

[LordMatt]

Well so long as there aren't blocking bugs (as there are now).

[KDR_11k]

The problem is that we had several serious bugs that weren't fixed in time for the 2007 deadline.

[Tobi]

I would argue that while we should preferably release with all or most of our bugs gone like we have been doing, we should instead release based on how many bugs there are in comparison to the current stable release.

thus the new release rule would be:

if bugCountSVN < bugcountStable then release

and not

if bugCountSVN == 0 then release

At least that way we have a larger user base to find issues we have more updates and we have a steady level of progress rather than large jumps every 5-6 months followed by 1 or 2 minor fix releases.

That's way to formal, I don't intend to wait till bugCountSVN == 0 but I only intend to wait till majorGameBreakingBugCountSVN == 0, where I personally decide for each bug whether it's major game breaking.

I don't think having released a half broken release earlier is an excuse to release a half broken release again (as your rule suggests). (And yeah I realize it would get better by one bug at least every release due to the < instead of <=)

That said, almost everything is finished.

I've one outstanding patch here that should fix jerkiness, and the only other thing that really needs some love is choose in game start positions. There are reports that suggest in 1v1 with spec as host colors/positions of teams are still borked in choose in game startpos mode.

[Tobi]

One blocking bug left, and some major ones that would be nice if fixed, but are not really release blocking.

http://spring.clan-sy.com/mantis/view_all_bug_page.php

Blocking one is specs/players that disconnect during load crash the game host, that really should be fixed. Would be very cool if someone could do that tonight

[LordMatt]

IMO it really would be nice if someone fixed hosted replays before release. :)