Login | Register

Development

Development

Release policy

OpenSIPS release policy is designed in such a way to be open (everyone is involved), predictable and reliable (know what to expect) and transparent (to the whole community).

  • Release interval
    • the release cycle is 1 year.
    • the release date is around second half of March for beta version and beginning of May of stable version
  • Release Planning
    • 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 TODO list ; docs must be realtime updated to reflect code changes
    • code freeze (no more additions) at T - 1 month ; trunk code is copied in a new separate branch
    • Release Candidate (or beta release)
    • testing, debugging during 1 month (or how long it takes) -> at T we have the General Available (GA) release (full stable release)

Version Management

From maintenances point of, there are two types of releases.

  • long term releases - will be supported for 2 years after it's release
  • standard releases - will be supported for 1 year after it's release

The only difference is just for how long they are supported. The releasing process, stability and everything else is the same for all.

This model aims to maintain a decent balance between getting features out the door and supporting the existing release. People wanting new features can go for the standard releases, and those looking for stability and better support can stick with the long term support releases.

By supporting a version, we understand troubleshooting, fixing bugs, and backporting various new fixes from more recent OpenSIPS versions. Also, we will take care maintaining packages and tarballs for the supported releases.

Once an OpenSIPS release moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs.


Page last modified on December 13, 2018, at 04:37 PM