Release policies

SIP Express Router - SERi's releases are like many open source projects divided into two types: stable and experimental. Stable releases are for production purposes and will be released about 9-monthly at a fixed date. Experimental releases are made available quite often, maybe every two weeks, but are not available to . Use the experimental release to try out new features and stay connected with the development process.

The process to a stable release

Roadmap creation

Features from the wishlist are accepted by the developers as part of a release. The discussions on which features to include are held on the mailing list Feature requests accompanied with patches are more likely to be included in the roadmap.

All the features and bugs are assigned to the milestone in the bug tracker. The management board participates in the discussion and formally approves the roadmap.


In the development phase, developers work on the features and bugs they volunteered for in the roadmap creation. Any development related to things on the roadmap should be coordinated with the developer in lead. Regularly, experiemental releases will be made available on major platforms for testing and feedback on new functionality and bug fixes.


Once most of the features have been implemented, the first pre-release (alpha) will be released. Pre-releases are considered to be ready for testing by the user community, but not ready for production. Several pre-releases may be released. About one month before the deadline for the release, a seperate branchi for the new release will be created. At this point, any development on the new branch (i.e. creation of a code tree separate from new development) is focused on fixing bugs and removing any features that cannot be finalized satisfactory before the release deadline. All the bug fixes to the branch are also made to the code repositoryi trunki (i.e. the code tree for new development).

Document production is done as part of the pre-releases process.


When a release date is reached, SER will be released with packages for a long range of platforms. Each SER release will have a corresponding SERWebi and SEMSi release that is tested to interoperate with SER.


Releases are named 0.a.b where a is the major release and b is the number of the bug-fix release. Example: Release 0.9.0 is a major release, while 0.9.1 is bug-fix release 1 for the 0.9 release. The branch in the code repository will be called 0.9.x (or historically 0.9.0).

Pre-releases are named 0.a.0-preX where X is the number of the pre-release. Thus, 0.10.0-pre2 is the second pre-release for the upcoming 0.10.0 release. Bug-fix releases will normally not have pre-release numbering, but be released directly (i.e. 0.10.1-pre1 does not exist, but 0.10.1 is released directly).

For historic reasons, SER has always been released as a 0. release. However, this naming does not show the maturity of the software.


Two stable releases are maintained with bug fixes at any given time. This is to make sure that large production setups have enough time to do testing and integration work for new stable releases. This means that if the latest stable releases is a.b, a.b and a.b-1 will be maintained. When a new a.b+1 stable releases is done, a.b-1 will no longer be maintained with bug fixes.

As there normally will be about 9 months between two major releases, you should make sure you upgrade within the 18 months a current stable release is being maintained. Please also note that developers may opt to release security patches to non-maintained releases, but that there is no guarantee.

Home |  Recent changes |  Search |  Glossary |  Sitemap |  Login