ESciDoc Core Publishing

We define a software snapshot which has passed all tests (tests may be incomplete) as build. Only builds are published. A build is therefore usable, but may contain major and minor bugs. A build could be tagged with a version number, depending on feature status. The interactive approach is kept, but we will split up the software publishing into two branches of builds:

Each branch is going to be subdivided into several builds:
 * Release
 * this branch is trimmed to bring up the next stable release
 * Develop
 * for enhancements
 * to test methods and application impact
 * not for productive environment


 * Release Branch
 * Stable Release (X.Y.Z)
 * use for productive environment
 * feature complete
 * highly tested
 * full documentated
 * Migration
 * Bugfix support
 * beta releases (X.Y.Z-betaXY)
 * use NOT for productive environment
 * use to test application interface
 * mostly feature complete
 * mostly tested
 * mostly documentated
 * migration might be incomplete
 * third party tests and bug reports are most welcome
 * daily build (X.Y.Z-betaXY-buildXY) (usually not published)
 * use NOT for productive environment
 * use to test upcomming fixes or minor changes
 * mostly feature complete
 * mostly tested
 * mostly documentated
 * migration might be incomplete


 * Developer Branch
 * daily build (buildXY) (equals the current developer builds)
 * use NOT for productive environment
 * structure may change dramatically between versions
 * feature maybe incomplete
 * methods maybe untested
 * interface maybe un-documentated
 * migration might be unsupported
 * software might be instable
 * third party tests and bug reports are welcome

The number of stable releases is going to be reduced to circa two per year. Stable Releases are supported with bugfixes if required. A bugfix version of released version 1.0 is for example 1.0.1. Non release builds contains a build number (e.g. 1.0.1-build23). Builds from the developer branch contains no version number in the name (e.g. build 520).