Versioning

FreenetIS versioning uses a three-digit number (ie, xxx).

• The first number is always 1 (version 2 has been written in Java EE and is not yet in sight)

• The second number is the most important, as it informs the extensive changes and added functionality. (can be seen in development plan)

• The third number information on patches and minor changes in the second version number.

Current version FreenetISu instance is stored in the file '/ version.php'.

Developer version ==

The above versioning is intended for distribution among the users ( ie in the branch trunk ) . For development purposes, added another item version prefixed by '~ ' . For this feature can be stated precisely one of the following items :

• ' Dev ' refers to the development version - located outside the testing branch (includes unstable and incomplete implementation of the new version )

• ' Alpha ' indicates alpha version - located in the branch , mainly in testing (includes partially completed implementation)

• ' Beta ' denotes the beta version - located in the branch , mainly in testing (includes shelf implementations suitable for testing )

• ' Rc ' stands for Release Candidate version - is in testing ( done debugged implementation to final test )

For item can still be a number that allows you to create multiple versions of the same item and arrange it for you. Sort versions ( used eg in [ http://wiki.freenetis.org/index.php/Autoupdate_DB_struktury Autoupdate_DB_struktury ] ) is identical to the order of the list ( ie dev < alpha < beta < rc ) . All development versions are sorted before the final version (xxx )

Example of versioning development

Consider a current version 1.5.0. We gradually develop version 1.6.0, our progress in versioning could be the following:

• Several developmental version in a separate Branch (1.6.0 ~ dev1, dev2 ~ .6.0, ...).
• The result of the development costs progressively as the alpha version (1.6.0 ~ alpha1, 1.6.0 ~ alpha1, ...).
• After completing all of the major changes we merge into testing, which we denote as ~ 1.6.0 beta, and debugging released the beta version.
• After debugging offer users even in testing RC if you find errors, fix them and release another RC (1.6.0 ~ rc1 ...).
• If everything is OK we will merge into the trunk and head version (1.6.0)
• If you are found after the release of some errors we publish them as versions 1.6.1, 1.6.2, ... for as long as you do not declare for an unsupported version.