When you create a deployment archive or upload a project to the Mendix 3.0 Cloud, you have to specify a version number. This version number identifies the release you are doing. On the Team Server the state of the repository is tagged with this version number so that you can always trace back what you released.
The version number consists of four numbers: major, minor, patch and revision. The fourth number, revision, is fixed and corresponds to the number of the latest Team Server revision that is included in the release. Major, minor and patch numbers are yours to choose, but it helps to follow a convention.
Typically, a major version increase means that major new functionality has been added (an “invoicing” module for example) or the workflow has changed considerably. A minor version fixes problems and adds small features to existing functionality. A patch release, finally, fixes a critical bug and does not change the domain model. A patch release should be interchangeable with another patch release with no changes to the data.
With the Mendix technology we did not follow the rules outlined above ourselves. In the 2.x line we did not change the major version number for years even though we added major new features: internationalization, microflows etcetera. We will practice what we preach from version 3.0.0 and up. The first maintenance release that fixes some problems and adds small features will be named 3.1.0. Once we add major new features again the version number will be 4.0.0. This more clearly communicates the scope of releases and besides, faster version numbering is all the rage these days!