From dabbe3fca90d6b94da390ddec5a81fd672996682 Mon Sep 17 00:00:00 2001 From: Dan Mulloy Date: Tue, 2 Dec 2014 16:20:03 -0500 Subject: [PATCH] Clarify the compatibility section --- Readme.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Readme.md b/Readme.md index 278792a5..60dc3283 100644 --- a/Readme.md +++ b/Readme.md @@ -133,19 +133,18 @@ try { } ```` -Compatiblity +Compatibility ------------ One of the main goals of this project was to achieve maximum compatibility with CraftBukkit. And the end -result is quite flexible - in tests I successfully ran an unmodified ProtocolLib on CraftBukkit 1.8.0, and -it should be resiliant against future changes. It's likely that I won't have to update ProtocolLib for -anything but bug and performance fixes. +result is quite flexible. Aside from netty package changes, it should be resilient against future changes. +It's likely that I won't have to update ProtocolLib for anything but bug fixes and new features. How is this possible? It all comes down to reflection in the end. Essentially, no name is hard coded - every field, method and class is deduced by looking at field types, package names or parameter types. It's remarkably consistent across different versions. -### Incompatiblity +### Incompatibility The following plugins (to be expanded) are not compatible with ProtocolLib: