Updating
Updating Prism is straightforward, but it’s important to follow the correct steps to ensure a smooth transition.
Releases
Releases are intended to be stable and are suitable for production use.
Configuration Files
Additions to the configuration files will automatically appear. Changes will not, but these will be rare and should only ever occur in major version changes.
Database Updates
Database changes will be applied automatically when you start the server.
However, schema changes on large databases can take time, which will cause problems if done when the server is starting.
To accommodate these users we provide a command-line schema updater that does not require the Minecraft server to be running.
With your Minecraft server offline, database backed up for safety, run the following command to initialize a schema update:
java -jar prism-paper-<version>.jar schema-update“libs” Folder
If Prism uses a new/updated library it will automatically download that file into the libs folder.
Release versions should never require you to delete the libs folder, but currently Prism will not delete previous library jar files, so it can be beneficial to file cleanliness to delete the folder every update.
”locales” Folder
New entries into locales files should be automatic. Changes to existing entries are not. If in-game messages aren’t working correctly, you may need to delete the locales folder and restart the server.
Dev Builds
After new work is reviewed and tested privately, dev builds are published to our CI server.
While these are intended to be ready for use and wider testing, they may contain bugs. Ideally, the bugs should be minor and won’t cause significant issue for a production server.
Any breaking issues found in dev builds will be fixed quickly.
Schema updates may be present in dev builds and for larger servers, you may want to run the command line updater first. However, we do not publish release notes for dev builds so you should pay attention to github.
Versioning
Prism uses a version numbering scheme of major.minor.patch (e.g., 1.2.3).
When the major version changes, like 3 -> 4, it indicates a breaking change.
When the minor version changes, like 4.1 -> 4.2, it indicates new features or improvements that are backward compatible.
The patch version is for bug fixes and does not introduce new features.