MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002331Zandronum[All Projects] Suggestionpublic2015-06-27 01:592015-06-27 22:59
ReporterAlexMax 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0002331: Zandronum versioning overhaul
Description'http://zandronum.com/forum/showthread.php?tid=6102 [^]'

This thread got me thinking about a couple of problems of the current Zandronum versioning system, mainly surrounding network protocols and testing releases.

1. Forcing the client and server version to match exactly by default is, frankly, obnoxious in some cases. I tried to use edward-san's version of Zandronum, which had the desync problems fixed, and players couldn't connect to my server. I had to apply the fixes as a patch against a stock 2.1 checkout.
2. On the other hand, if there is a new version of the Zandronum client that is released, you want to have players on that new version as soon as possible. For this, having the server inform the client that they are out of date is a good thing. But do demos have to break too?
3. And on the third hand, if you're running testing sessions, sometimes you want the freedom to be able to make updates to the server without the player having to download a new client, and sometimes it's important that the client isn't using an older testing client that will exhibit bugs that have already been fixed in a newer version.

To that end, I say that we overhaul how versions work in Zandronum. Not the visible version string that we tell everybody, but some under-the-hood stuff that we can use to allow for automatic updates and easy downloading of proper testing releases. How about we have these?

1. A "protocol version". This protocol version is updated by the developer anytime the network protocol changes in a backwards-incompatible way. Make it 32-bits, so developers don't feel bad about bumping it. For recording and playing back demos, this is the only version that will ever be checked.

Why: To prevent incompatible clients and servers from talking to each other.

2. A "real version". This would be "2.0", "2.1", and would be updated for every stable release of the Zandronum _client_. If an unmatched client tries to connect to a server, it will refuse to connect them, even if the protocol version matches. Note that this would _not_ be bumped for point releases that are only relevant for servers.

Why: To ensure that players are always using the latest stable release of the client, even if the protocol doesn't change.

3. A "channel". This would be "stable" or "testing", and would be "stable" for almost any stable release of Zandronum, and "testing" for almost any testing release. This is also a blocker - stable client can't join a testing server and vice versa.

Why: Doomseeker will use this field in combination with the protocol version to figure out what version of the Zandronum client to download and use on that server. If it's "stable" and protocol version 67, it will use download and use the latest stable release on protocol 67. If it's "testing" and protocol version 92, it will download and use the latest testing release on protocol 92.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-06-27 01:59AlexMaxNew Issue
2015-06-27 09:17ZalewaNote Added: 0012808
2015-06-27 10:25LeonardNote Added: 0012809
2015-06-27 13:32DuskNote Added: 0012811
2015-06-27 13:40DuskNote Edited: 0012811bug_revision_view_page.php?bugnote_id=12811#r7545
2015-06-27 13:41DuskNote Edited: 0012811bug_revision_view_page.php?bugnote_id=12811#r7546
2015-06-27 22:54Konar6Note Added: 0012816
2015-06-27 22:59Konar6Note Edited: 0012816bug_revision_view_page.php?bugnote_id=12816#r7550

Notes
(0012808)
Zalewa   
2015-06-27 09:17   
I think that might be the best solution that we could have in the current environment.

The simpler, and less elastic one, would be just to maintain only one instance of zandronum client installation and ask zandronum.com what's the newest version and compare it against that local client executable, but to achieve this the client executable must be able to report its version somehow.
(0012809)
Leonard   
2015-06-27 10:25   
I fully agree with everything you said.
This could also make things easier for custom clients.
For example, since we started using bitbucket for ZCC, I have to override svnrevision.h each time I compile to be able to connect to servers which is annoying since it will show up when committing later on.
(0012811)
Dusk   
2015-06-27 13:32   
(edited on: 2015-06-27 13:41)
While I agree with this ticket wholeheartedly for the most part, I must note that while 0002329 is server-side only, we've also had similar problematic tickets such as 0002116 that were client-only. So we need to be able to push client-only updates too.

So how about this: have the protocol version and Zandronum version correspond for the most part, except that point releases do not affect protocol. For instance, we're currently at 2.1 with a server-only bug, so we should release a 2.1.1, which is network-compatible with 2.1. Only servers have to upgrade. Suppose we had to deal with 0002116 instead, players would have to upgrade instead of servers. Doomseeker could then query what is the latest update for clients.

This does however carry the problem that for clients, 2.1 and 2.1.1 are the same. If a 2.1.2 was released with client-only changes, 2.1.1 could get a bit confusing since it never had to be installed, though I don't think this will be too much of a problem.

This kind of system would allow us to latch only the protocol version and push considerably more frequent updates that only affect the client and server without protocol changes, followed by a protocol upgrade every x months. My primary worry though is that the optionalness of such releases can downplay important security fixes such as 0002116. So we should be able to flag a non-protocol-affecting release as an important update, too (or just bump the protocol version without actually changing the protocol to ensure everybody updates).

This is possibly a bit of a stretch but perhaps we could do what we're doing with RCON protocol and add minor protocol updates that are sent to clients who can understand the updated protocol? For example, send a variable to certain clients only if such clients are up to date enough, which would allow us to maintain more dynamic versioning to keep things up to date. When a new minor release is done, all of these are removed. To ensure nothing is lingering we could e.g. conditionally define a method which handles this, whose absence would trigger a compiler error.
(0012816)
Konar6   
2015-06-27 22:54   
(edited on: 2015-06-27 22:59)
Patch releases (like 2.0.1) should have no protocol changes, they should be released to make simple enhancements or fixes to either the client or server and thus should be network compatible. In case the protocol is changed, a minor release (like 2.1) should be made. This should be the difference between minor and patch versions (ZDaemon anyone? You could play with 1.08 client on 1.08.08 server and vice versa). It would also make the extra "network version" in stable builds obsolete.