-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Somehow exchange versions in a way that won't add too much overhead and won't break #2
Comments
Yes, exchange versions. Maybe make some versions backwards compatible but only as far as possible? E.g. client sends 0.2.4 and server is running 1.3.7, no problem, but e.g. client sends 0.1.0 and server is 1.8.4 (where the client doesn't even have support for roles) it would deny the connection? That'll probably be slow, hard and messy but it's just an idea. |
That's the entire point of semver. <major>.<minor>.<patch>. I don't increase major if they're not compatible. |
I just thought of an issue: What if somebody makes their own server side application? We can't force them to use the same version numbers as us? |
Another issue: How should the version even be exchanged? The protocol might change completely which means it breaks the version exchange... And unless we put it in the LoginSuccess packet we'd need to make a whole new packet for the version stuff, which would be annoying. |
BUMP |
Currently an incompatible client will work until it doesn't. Then it will start behaving weirdly and nobody will know why.
Would it be better if errors could be detected earlier on?
Pros:
Cons:
The text was updated successfully, but these errors were encountered: