With the release of PocketMine-MP 3.0, we've changed how our release flow works to sit with the new versioning scheme. Currently there are three mainline branches available (which can be seen on GitHub): `release/3.0` - New 3.0.x releases are created from this branch. This branch receives bug fix updates only. These bug fixes are rolling out fairly frequently. `release/3.1` - 3.1.0 is under development on this branch. This branch is NOT PRODUCTION READY, it's in testing. New features are being added to this branch, provided that they don't break backwards compatibility. `master` - As always, this is the bleeding-edge branch. 4.0.0 is under development on this branch. This branch is also NOT PRODUCTION READY. Changes that break backwards compatibility land on here. Spoiler: Old version support debate Over the years it's become very apparent that the release flow needed significant improvements. I want to thank @FiberglassCivic for opening my eyes to this, even if I wasn't very friendly about it at the time. Since ALPHA10 was released, there have been efforts to maintain branches of release versions, that receive protocol updates only. This was intended to ensure that server owners could easily and quickly update their servers without having to rewrite all their plugins (we saw this with alpha5, alpha6, alpha7, alpha9). However, as we know this release flow was still ineffective. People continued to use development builds because they needed bug fixes in newer versions, wanted new features or whatever. it also made it difficult to create new distinguishable releases without the Jenkins build number. Spoiler: Plans for release flow in the future With the new versioning scheme now in place, we're aiming to iron out the issues that have arisen with the release flow in the past. Currently, the plan looks like the following (although it may change): Support a current stable version with bug fixes and protocol updates. Currently, this is PocketMine-MP 3.0. Develop a next feature update version that does not break backwards compatibility (if possible). This will be the upcoming 3.1.0 release. When the next feature version is released, terminate support for the previous feature version. Since feature updates should not break BC, this should be fine. Develop a next major version that does whatever is necessary. This will be 4.0, which is expected to be released in 2-3 months' time. When a new major release is created, terminate feature update support for the previous major version. This means that the previous major will receive protocol updates and bug fixes, but no new features. Support the previous major release for a grace period to allow users to comfortably upgrade. This grace period may last a few weeks to give everyone comfortable time to upgrade to the new major version. For the present, the plan is as follows: 3.0.0-ALPHA12 will continue to receive protocol updates only until Minecraft PE 1.5.0 is released. At 1.5, support will be cut for ALPHA12 completely. 3.0.x will receive protocol updates and bug fixes until 3.1.0 is released, at which point 3.0.x support will be cut completely. 3.x.x will be supported with feature updates, bug fixes and protocol updates until 4.0.0 is released. At this point, 3.x.x will stop receiving feature updates. A grace period (which will be determined after 4.0.0 release) of support will be given to 3.x.x after 4.0.0 is released, to give users time to upgrade.