DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
| Note | ||
|---|---|---|
| ||
This document is subject to change without notice. |
We utilize semantic versioning as defined here:
...
Fineract releases may be qualified by text following the version number, which all represent various steps in the pre-release process. In order from least- to most-stable:
| Pre-Release Qualifier | Meaning | Example | Alpha | |
|---|---|---|---|---|
| snapshot[+<x>] | A release currently in development. The contents of x are optional, freely defineable, and mean something only to the person creating the snapshot | We know or expect there to be problems, but solicit testing from interested individuals. | 1.1.0- | alpha2snapshot+myrlesbuild23 |
| m.<whole number> | Milestone. We know or | Beta | We don't expect there to be problems, but be wary just in casesolicit testing from interested individuals. In case there are multiple milestones, they are numbered. The larger the number, the more advanced and (theoretically) more stable the release. | 1.1.0-beta1m.0 |
| rc.<whole number> | Release Candidate. | RC (Release Candidate) | This release is a candidate to become the final proposed version. If no serious bugs are found, the -rc tag will be dropped, and the contents of this release will be declared stable. | 1.1.0-rc4 |
...
| rc.0 | ||
| <none> | If there's no pre-release qualifier, it's a release, not a pre-release. | 1.1.0 |
First release
Our first release of Apache Fineract will have a major version of 0. It is not yet determined when we will iterate that release version to 1. We do not commit to avoid breaking compatibility inside of a major version until we iterate the release version to 1. (Once we've done that, we can delete this section too.)
Milestone releases
When we want new features to get wide testing before we enter the formal stabilization period, we 'll will sometimes release alpha and beta milestone versions. There is no requirement to do any beta releases even if there were "alpha1", "alpha2", etc releases; we multiple milestone releases. We could just jump straight to "rc1". However, there are circumstances where a beta can be useful: for example, if we're unsure of a decision and want to get wider user feedback before solidifying it into a formal release candidate.
...
rc.0".
Milestones are for people who want to help test, and who understand that there may be incompatible changes before the final release.
Breaking compatibility
Our compatibility rules only start to apply once a final x.y.0 version has been blessed and released. Any API's, wire protocols, and on-disk formats that appeared on trunk or in an alpha/beta/rc pre-release are not subject to any compatibility promises; we may change them arbitrarily until the final release, if we find a good reason to do so.
In particular we might not provide an upgrade path for persistent data with the final release. Consequently, pre-releases should never be trusted with any data meant for long-term safe-keeping.
At the same time, we wish to remind the reader that the best time to point out API design bugs is before they are released and set in stone during the initial design and pre-release stages.
(Thanks to the Subversion team for the content we 'borrowed' from the Subversion release guideline)