Join GitHub today
Jumi's version numbers follow the MAJOR.MINOR.BUILD format. This format is a compromise which mostly follows Maven's version schemes and Semantic Versioning, while at the same time supporting Continuous Delivery. The following are the guidelines for version numbering in this project:
The MAJOR version is incremented for incompatible changes for which an incremental transition period is not possible. Incrementing MAJOR resets MINOR to 0.
The MINOR version is incremented for new features worth mentioning and for deprecation of public APIs. They are backward compatible with all previous releases which have been released within the transition period (for example within last 6 months). If a consumer upgrades less often than the transition period and skips some MINOR versions, then an incompatible change is possible. Incrementing MINOR does not reset BUILD.
The BUILD version is incremented for every build (on the official CI server), even if it's not released for general public. This is to accommodate continuous delivery, where every build is a candidate for release and every binary is built only once (see this article about Jumi's build pipeline). Not every binary is released, so there will be gaps in the BUILD versions and the consumers won't be able to guess the version numbers. We hope that this is not much of a problem in this age of search, copy and paste.
During development the version numbers are in MAJOR.MINOR-SNAPSHOT format (e.g. 1.2-SNAPSHOT). Then when a build is made, the CI server will replace "-SNAPSHOT" with the build number (e.g. 1.2.595) without committing the change. The build artifacts are saved to a staging repository and integration tests are run against the staged artifacts. If the build is deemed good and worth releasing, the staging repository's contents are copied to the Maven Central repository.
Versions whose MAJOR is 0 are builds which still lack some hygienic features, though the features which exist should be bug-free. Also the public APIs may change more frequently, even incompatibly, than they will after a 1.0 release.
Eventually Jumi will have a plugin system. The plugins will be deployed to a repository from where they can be installed and upgraded. Plugin compatibility will be determined individually for each build using a whitelist. If a plugin binary passes its integration tests against a particular Jumi build, then it will be marked compatible with that build. Until that happens, Jumi won't run the plugin (unless forced to).