commit 15d7171defded3bcac2073fdc668a3fe3d77e0df
author mastercoms <circuitsoft@tuta.io> Mon Feb 06 11:23:13 2017 -0500
committer GitHub <noreply@github.com> Mon Feb 06 11:23:13 2017 -0500
tree 55b7b4147b2c6606da49a204c2d92d563a62b2e4
parent f63bed32b8a44334bb596e402f5460c70e87dfe6

Update version based on new schema

We are moving to time-based releases, as a project such as Glowstone will not have a good place to release a new version, since there is a lot to fix and develop. 

The new versioning scheme is `YEAR.release.major.minor`.

Our previous schema didn't have much of a point to the year part of the version besides to set ourselves apart from the Minecraft version to prevent confusion. Now, development cycles will be determined by the year version. Every year, we will release a version of Glowstone labeled as stable in January of that year. That stable release will be worked on in December of the previous year with a complete feature freeze, so only bug fixes and stability improvements may be worked on during that time frame. The stable release will be released as year.0.major.minor, so the release version will always stay at 0. 

Once the stable version has been released, the freeze will be lifted and development will start on version year.1.major.minor, with the release version incrementing on Minecraft major version updates and other huge changes to Glowstone. As for the major version, that will increment every month and will coincide with a release announcement on the blog at the beginning of each month. The minor version will remain the same as the previous schema's trivial version, incrementing on every change (commit or commit series). This requires commits or commit series to have a well defined scope, as defined by the commit message. We can only provide support for the latest development version.

The versioning scheme is slightly different for stable releases. A new branch will be made for every stable release, and while the release version will not change from 0, the major version (backport version) will increment when fixes from master are backported to the stable branch. These will come usually every month. The minor version (hotfix version) will increment when we need to immediately patch a crucial bug that is discovered or one that came about from a backport. We will be supporting these stable releases with fixes and technical assistance for the entire year. (For example, the 2018 stable release, 2018.0.x.y will be supported during 2018 only.)

I hope this new versioning scheme will help us develop features and fixes better for you. If you have any questions, comments or concerns, feel free to comment on this commit or contact me on Discord.