-
Notifications
You must be signed in to change notification settings - Fork 247
Enable servers and clients to declare compatibility with public servers. #830
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
Draft
rfortier
wants to merge
1
commit into
tiltedphoques:dev
Choose a base branch
from
rfortier:feat/Enable-public-server-compatibility
base: dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not sure about this:
From my experience, things like this are almost always end up abandoned, especially when new maintainers come
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have made it plain you don’t like the PR, pointing out potential problems while ignoring the benefits to the community. You have not offered any constructive criticism that is also feasible to implement without magic.
I object to the fears you are voicing, as the disasters you predict require incompetence on the part of the author for the disaster to come about.
Present an improvement that is feasible. Otherwise, I stand by the design and the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big fan, just because the protocol might be compatible between versions does not mean that other behaviour(s) weren't changed between versions.
And since dev releases don't increment the overall version there is no point in providing workarounds 😅
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your first point, "does not mean other behaviour(s) weren't changed" is the point I've been trying to make all along too.
The back-and-forth with Miredirex started over this point, that we should be able to compute if the bits in the protocol have changed. Might be technically possible but that is an inadequate solution because it may be that there is no change in the wire protocol at all, but just a semantic / interpretation / behavior change that renders a new version compatible or not. That requires human review to decide.
Even then it can be ambiguous, or at least a decision as to which way to go. The current Vampire Lord animation fix is a case in point that can be used for a discussion example.
At first, M. said it was incompatible because it was a server-side change, implying a wire-protocol change also. But reviewing the final version showed it was only a behavior change with no wire protocol change. If you had the server-side fix, the Vampire Lord transformation fix would be seen by clients, even older clients. If you used even a newer client with the older server, it would work just fine, you just wouldn't have the animation fix.
So, is it compatible with 1.8.0 servers or not?
I'll argue it is compatible, because that is better for the community. People on a fork/branch with the fix can interoperate with 1.8.0 clients and servers with no issues other than a cosmetic one. When a release comes out with the fix, it will still interoperate with the public servers like PlayTogether. Those providers can update at their leisure, or even skip an upgrade cycle if we think another maintenance release will be "soon."
Everyone wins, IMHO.
Now, it's not quite true with the current state of the PR. Taking into account past discussions with the team, there is a clear bias against dealing with version compatibility. So, the current PR ensures that an IS_MASTER build will never make a compatibility declaration.
But, we could choose to change that; the example I just cited above makes a pretty good case for doing so. Plus, the makeup of the team maintaining the mod and approving PRs has changed. The new guard may come to a different conclusion than the old guard; I'm providing that option.
One last point: I have to do this in the fork anyway. It is a better and more supportable solution than having the fork "lie" that it is v1.8.0 just so it will work with the public servers (which is what the fork used to do, and I just think that is dangerous).
This way it can have a distinct version number while still maintaining compatibility, which is far better for hunting down bugs.
If the PR is rejected, the code can just live on in the fork as a "best we can do" solution, as @miredirex suggested. But there are benefits to other branches or forks if it goes in. Like fixing the fact Dev branches can't have distinct version numbers for each new build without breaking compatibility.