-- FILE ---------------------------------------------------------------------
-- name       : BuildVersioning.txt
-- project    : BoarderZone: Development Environment
-- created    : Leon Poyyayil - 2004-08-16
-- language   : English
-- environment: the human readers mind ... ;-)
-- copyright  : (c) 1990-2024 by Leon Poyyayil (private), Switzerland
-- license    : this is free software licensed under the GPL. see COPYING
-----------------------------------------------------------------------------

This file contains a description of the release and versioning scheme for builds.

A description of the code changes between various builds can be found in the
file BuildNews.txt wherein the different builds are listed such that the most
recent one is located at the beginning of the file. The file ReleaseNews.txt in
contrast contains only those changes which are relevant to end users.

Tracking of changes in this manner started with build 100.

The status of a build can be one of the following:
- release:           a fully functional state
                     -> distribution to the customer for test & deployment
- beta:              a fully functional state for beta-testing etc.
                     -> distribution only to development/partner/customer
                     -> features are fixed
                     -> api is fixed
- alpha:             a feature frozen state which is intended to propagate
                     first to 'beta' state and then to 'release'.
                     will be used for functional testing.
                     -> features are fixed
                     -> api might still change
- developmental:     a build to freeze the current state for later reference
                     a most probably stable state of the whole system but
                     with still missing functionality
                     -> not intended for distribution
                     -> new features will get added and old ones removed
                     -> api will undergo (possibly heavy) changes
- proof of concept:  no longer used

Propagating a build from 'developmental' to 'alpha' means to freeze the
functional state for a later 'release' (after a 'beta' phase). Thus further
new development should go into a new 'branch' which should be indicated by
adapting the version numbers accordingly:
- The minor (and possibly the major) version numbers should indicate
  the new version, which means either of two possible scenarios:
  - The major version stays the same and the minor version is incremented
    by one. This indicates a next release with comparable feature set but
    some new functionality and enhancements.
  - The major version is incremented by one and the minor version is
    reset to zero. This indicates a next release with substantial new
    features.
- The build number should be incremented by some amount which allows further
  alpha/beta/releases to be created with distinct build numbers.
  It is suggested to increase the build number by at least twenty. Thus if
  the current (alpha) build is 117 then further development should go into a
  next build with number 140. This gives room for 22 builds for alpha and
  beta testing and possible hot fixes.

Thus a possible version/build history could look as follows:

0.1.100-developmental   initial build
0.1.101-developmental   new functionality
0.1.102-developmental   new functionality
0.1.103-alpha           feature freeze for testing and later release
0.1.104-alpha           bug-fixes
0.2.130-developmental   new development for next version
0.1.105-alpha           further bug-fixes
0.1.106-beta            beta testing release
0.1.107-beta            another beta testing release with some fixes
0.2.131-developmental   further new development for next version
0.1.108-release         the final release for distribution
0.2.132-developmental   new functionality
0.2.133-developmental   new functionality
0.1.109-release         hot-fixes for the distributed release
0.2.134-alpha           feature freeze for the next version
0.3.160-developmental   already new devs

So this means there is a main development trunk with continous build numbers
and ever increasing versions from which the alpha/beta/release branches fork
off:

0.1.100 - 0.1.101 - 0.1.102 - 0.2.130 - 0.2.131 - 0.2.132 - 0.2.133 - 0.3.160 - ...
                       |                                       |
                    0.1.103                                 0.2.134 - ...
                       |
                    0.1.104
                       |
                    0.1.105 - 0.1.106 - 0.1.107 - 0.1.108 - 0.1.109 - ...

This shows that build numbers alone are enough to unambigously identify an
executable, and not the full version is required. Like this, within a line of
development (builds with the same version numbers) the build numbers are
continous. And within the development line the build numbers are ever
increasing.

-- EOF ----------------------------------------------------------------------