OpenSIPS Release Policy
The OpenSIPS software release policy is designed in such a way to be open (anyone can get involved), reliable (know what to expect) and transparent (to the whole community).
- Release Interval
- the major release cycle is 1 year
- the beta version release date is around the second half of March
- the stable version release date is around the beginning of May
- Timeline of a Release
- open brainstorming on what the next release should contain.
- compile a TODO list for the next release to fit the time frame; list may be dynamically updated.
- actual work on implementing the items on the TODO list; the docs must be updated in real-time to reflect code changes
- code freeze (no more additions) at T - 1 month; master branch code is copied in a new separate branch
- Release Candidate (or beta release)
- testing, debugging during ~1 month -> at T we have the General Available (GA) release (full stable release)
Major Release Flavors
The flavor of a release affects both its content (choice of features), as well as its maintenance timeline. There are two flavors of major releases:
Standard Releases
- will continue to be supported for 1.5 years after the initial release
- are typically odd-numbered: 2.1, 2.3, 3.3, etc. Exception: 3.1, which is an LTS release.
- are expected to contain more substantial changes coming from the previous, even-numbered LTS release. A standard release is more likely to contain a significant rework of a certain critical area of the codebase (think: networking protocols, inter-process communication, async engine, DB layer, etc.), a major script syntax change or a partial or complete rework of even the most popular of modules (if it's for the better, of course!).
- will often include the more ambitious, high-complexity and high-risk features from the development TODO list (in terms of code refactoring volume and potential for introducing regressions).
Long-Term Supported Releases (LTS)
- will continue to be supported for 3 years after the initial release
- are typically even-numbered: 2.2 LTS, 2.4 LTS, 3.2 LTS, etc. Exception: 3.0, which is a standard release.
- are expected to contain less substantial changes coming from the previous, odd-numbered standard release. An LTS release will often include safe features, which cannot affect large parts of the OpenSIPS runtime or cause substantial script syntax incompatibilities with the previous release.
- will often benefit from more stress-testing, performance regression testing, performance optimizations and the well-contained, straightforward or low-risk features from the development TODO list.
This "standard vs. LTS" release model aims to strike a good balance between shipping more complex, time-consuming and high-risk features (e.g. the major rework for async support in 2.1, major rework for switching to JSON-RPC communication in 3.0, the major module function parameter rework in 3.1, etc.), as well as taking the time to test the codebase for either performance regressions or key code bottlenecks which could highly benefit from optimization. Experienced VoIP developers, early adopters and OpenSIPS power users should opt for the standard releases, while users looking for a battle-tested, stable and better supported release should choose a long term supported release.
By supporting a version, we understand troubleshooting, fixing bugs, and backporting various new fixes from the more recent OpenSIPS versions. Also, we will take care to maintain packages and tarballs for the supported releases.
Once an OpenSIPS release moves to unsupported status, it will not get any new bug fixes, re-packaging or new tarballs.
