Versioning
How Versioning Works
When we are releasing an update, we follow a very simple versioning system. Hopefully this document will avoid some of the questions asked whenever a new version is released.
Overview of the Versioning System
We use 3 separate numbers in our version scheme: MAJOR.MINOR.BUILD
On some occasions, you may see BETA or DEV after the version number. For example: PITS v1.0.0-DEV would be released as an Alpha file, while PITS v1.0.0-BETA would be released as a Beta file.
On our Continuous Integration server, you may see colored stars next to some builds. Red stars indicate Development builds, orange stars indicate Beta builds, while green stars indicate Recommended builds. If there is a gold star next to a build, that build has been released on BukkitDev, and is the best build you can get unless there is another gold star higher in the build history.
It is always recommended to update to the latest major recommended release to ensure your installation is kept up to date.
Major Version
The first number in the example given above is 1. This means it is the first major release of the plugin. An increase in the major version number indicates some major changes have been made, and is therefore not backward compatible. Version 2.0.0 is not compatible with version 1.0.0 and so on.
Whenever a major release of the plugin takes place, the web interface will be updated to reflect the changes. The same holds true for for the web interface in that if a major change happens there, the plugin is also updated.
Version 1.0.0 of the plugin will not work with version 2.0.0 of the web interface, for example.
Minor Version
The second number in the example is 0. This means the release is the first minor release. An increase here indicates minor changes that don't affect the overall functionality of the plugin. A web interface release usually accompanies a minor release, but not always.
A newer minor release is almost always backward compatible with an older one, unless otherwise stated.
Build Number
The build number is changed when the internal code structure changes, but no features were added, changed, or removed. It is not uncommon for the build number to "skip", going from 1.0.2 to 1.0.10 for example. It can also increase if the code was optimized in some fashion.
A release with a higher build number is always backward compatible.
Development Stages
There are currently 5 stages of our development: Bleeding Edge, Development, Beta, Recommended, BukkitDev Release.
Bleeding Edge builds can only be found on our CI system. It is NOT recommended for use on live servers as unexpected events could happen, possibly leading to an unstable server. These are built automatically whenever a change has been pushed to our repository, triggering a build. These builds have no star next to the build within the CI system.
Development builds can either be found on our CI server indicated by a red star, or on BukkitDev. If released on BukkitDev, it will be flagged as Alpha in the files section. The decision to promote a build from Bleeding Edge is made if tests have determined no catastrophic side effects can possibly occur. Even though these builds are more stable, the feature set and code are still constantly in flux. Its never recommended to update a live server from a stable, recommended, and BukkitDev release to a Development build. We rarely release Development builds on BukkitDev. NOTE: Development builds are entirely unsupported.
Beta builds are even more stable and can be found on BukkitDev more often than Development builds. These builds are promoted more often than Development builds, and are supported within our ticket system. The decision to support Beta builds is important, as the community is involved in the testing process starting at this stage. Beta builds can be identified by an orange star within our CI system.
Recommended builds are stable and are safe to use on live servers. Builds promoted to this stage are always released on BukkitDev. These builds are identified by a green star within our CI system.
Promoted releases are extremely stable and are the best builds to use on live servers. Builds promoted to this stage are feature frozen. This means no features in the current release branch will be added, changed, or removed. No code changes can happen at this stage. A build promoted to this stage typically indicates work has started or will be started on the next major version. These builds are indicated by a gold star within our CI system, and by a [P] before the name in the BukkitDev release system.
Comments