This document covers the structure of chan_misdn releases. 

chan_misdn has got more and more stable lately, also a lot of new features are
added which means that new potential bugs came into the code.

Projects like linux and asterisk show, that it is possible to add new
functionality in a head like branch of the software and to feature-freeze
stable branches.

chan_misdn will from now on follow this path. We will start a stable release
now which will have the version 0.2.0 This version will have Subversions
(0.2.x) if major bugs are fixed. Additionally we will have the head branch
wich will be called unstable, so that this version is only used by friendly
testers and volunteers.

Currently there are 3 Major Versions: 

0.2.X	- stable Version with a lot of limitations regarding Kernels and
	distros, is not developed anymore
0.3.X	- upcoming stable, highly developed (0.3.1 - will be released as 
	stable soon)
0.4.X	- new highly experimental features


On our webside we will have new directories: 

www.beronet.com/downloads/chan_misdn/stable/
www.beronet.com/downloads/chan_misdn/unstable/
www.beronet.com/downloads/chan_misdn/releases/

stable will point to the current stable release with all the bug-fixed versions.

unstable will point to the current head branch with multiple release
candidates, which contain bugfixes and additional features.

releases contains all releases with their testing and stable tarballs. where the structure is like:

release/old
release/V0.1
...
release/V0.N
release/V0.N+1


The last release will be the unstable, and the previous one (in the above case version N) will be the stable.


stable case:
------------

each release subdirectory will contain a candidates directory in which the prereleases lay which can be tested, 
the prereleases have the name of the next subrelease with an additional -rcX postfix, this indicates that this 
version is free for testing and will become the next stable release.


In the version directory the nameing-scheme will be: 

chan_misdn-X.Y.Z , where X is the current major release number, Y is the current
minor release number and Z the newest patchlevel with bugfixes.

All the tarballs in with that naming-scheme are stable. Lets assume Z is the last patchlevel, newer bug-fix 
candidates in the candidates subdirectory will then contain tarballs with the name: 

chan_misdn-X.Y.Z+1-bfN

those can be tested, when all the bugs are fixed we can release chan_misdn-X.Y.Z+1.

an example may clarify this scheme: 
-----------------------------------

At the begining we anounced 0.2.0 as stable. Newer bugfixes were made and went into the 0.2.1-rc1 Version which lays in:
releases/V0.2/candidates/chan_midsn-0.2.1-rc1.tar.gz

When we have reached rc20 and think it is stable enough, we can release chan_misdn-0.2.1 which will then live at:

releases/V0.2/chan_misdn-0.2.1.tar.gz


unstable case:
--------------

The nameing scheme will be pretty the same like in stable, only that there's no stable release at all. There are only 
release-candidates which will have a rcN suffix. When we think the current unstable got enough features and is stable 
enough, we will open a new unstable release and anounce the current unstable as stable.


This will ensure that the stable branch of chan_misdn will not longer get any
new features but only bugfixes. This branch can be used in production
environments.