• will often include the more ambitious, high-complexity and high-risk features from the development TODO list (in terms of code refactoring and potential for regressions).

• will often include the more ambitious, high-complexity and high-risk (in terms of code refactoring and potential for regressions) features from the development TODO list.

• are typically odd-numbered: 2.1, 2.3, 3.3, etc. Exception: 3.1, which was an LTS release.

• are typically even-numbered: 2.2 LTS, 2.4 LTS, 3.2 LTS, etc. Exception: 3.0, which was a standard release.

The type of a release affects both its content (choice of features), as well as its maintenance timeline. There are two types of major releases:

Types of OpenSIPS Major Releases

OpenSIPS Version Management

From a maintenance point of view, there are two types of major releases:

• will continue to be supported for 1.5 years after the initial release

• will continue to be supported for 3 years after the initial 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.

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 code 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.

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 time to test 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.

This "standard vs. LTS" release model aims to maintain a decent 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 time to test 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.

• are expected to contain less substantial changes coming from the previous, odd-numbered standard release. An LTS release will often include well-contained, safe features, which cannot affect large parts of the OpenSIPS runtime. LTS release

• will often benefit from more stress-testing, performance regression testing, performance optimizations and the more well-contained, straightforward or low-risk features from the development TODO list.

• will often include more performance regression testing, performance optimizations and the more well-contained, straightforward, non-invasive or low-risk features from the development TODO list.

• will often include more performance regression testing, performance optimizations and the more well-contained, straightforward or non-invasive features from the development TODO list.

• will often include more performance regression testing, performance optimizations and the more straightforward and non-invasive features from the development TODO list.

• are typically odd-numbered, e.g.: 2.1, 2.3, 3.3, etc. Exception: 3.1, which was an LTS release.

• are typically even-numbered, e.g.: 2.2 LTS, 2.4 LTS, 3.2 LTS, etc. Exception: 3.0, which was a standard release.

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

• 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

• 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.

• compile a TODO list for the next release to fit the time frame; list may be dynamically updated.

• compile a TODO list for the next release to fit the time frame; list may be dynamically updated.

• the release cycles is mainly time driven : a release each 5-7 months. Inside that intervals, what date will be is feature driven, depending on the required volume of work.

• estimating the release time (T) based on the volume of work (between 5-7 months)

• SVN freeze (no more additions) at T - 1 month ; SVN trunk code is copied in a new separate SVN branch

(:toc-float Table of Content:)

OpenSIPS Experimental

• Take a look at the new design overview and also see the stage1 available features and how to download it.

Developers hierarchy

To ensure the quality and technical competence across the project, the development work is governed by developer knowledge.
OpenSIPS project implements several layers of technical competence - the development hierarchy:

1. core developers - developers taking care of OpenSIPS core, of the overall architecture and design
2. module developers - developers taking care of a OpenSIPS module (or modules). They are module maintainers. For work expending across their modules they need to address to other module developers (for other modules) or to core developers (for core or global matters)
3. tool maintainers - developers not involved in OpenSIPS core or modules, but in surrounding tools and utilities (control tool, DB scripts, utilities, etc)
4. contributors - developers randomly contributing to OpenSIPS by providing patches (for fixes or new features). For how this works, see Contributing page.
5. packagers - people taking care of OpenSIPSpackaging (for different OS's) ; they are in-charge with maintaining the specs and preparing packages.

Module maintainers

1. acc - Bogdan-Andrei Iancu
2. alias_db - commonly maintained
3. auth - Bogdan-Andrei Iancu
4. auth_db - Bogdan-Andrei Iancu
5. auth_diameter - unmaintained
6. auth_radius - commonly maintained
7. avpops - Bogdan-Andrei Iancu
8. avp_radius - commonly maintained
9. benchmark - Bastian Friedrich
10. call_control - Dan Pascu
11. carrierroute - commonly maintained
12. cfgutils - commonly maintained
13. closeddial - Sergio Gutierrez
14. cpl-c - Bogdan-Andrei Iancu
15. db_berkeley - Will Quan
16. db_flatstore - commonly maintained
17. db_mysql - commonly maintained
18. db_oracle - commonly maintained
19. db_postgres - Greg Fausak
20. db_text - commonly maintained
21. db_unixodbc - commonly maintained
22. dialog - Bogdan-Andrei Iancu , Ovidiu Sas
23. dialplan - Anca Vamanu
24. dispatcher - commonly maintained
25. diversion - commonly maintained
26. domain - commonly maintained
27. domainpolicy - commonly maintained
28. drouting - Bogdan-Andrei Iancu
29. enum - commonly maintained
30. exec - Bogdan-Andrei Iancu
31. gflags - Bogdan-Andrei Iancu
32. group - Bogdan-Andrei Iancu
33. group_radius - commonly maintained
34. h350 - Christian Schlatter
35. identity - Bogdan-Andrei Iancu
36. imc - Anca Vamanu
37. jabber - Anca Vamanu
38. lcr - commonly maintained
39. ldap - Christian Schlatter
40. load_balancer - Bogdan-Andrei Iancu
41. localcache - Anca Vamanu
42. mangler - unmaintained
43. maxfwd - Bogdan-Andrei Iancu
44. mediaproxy - Dan Pascu
45. mi_datagram - Bogdan-Andrei Iancu
46. mi_fifo - Bogdan-Andrei Iancu
47. mi_xmlrpc - Bogdan-Andrei Iancu
48. mmgeoip - Kobi Eshun
49. msilo - commonly maintained
50. nathelper - Bogdan-Andrei Iancu , Maxim Sobolev
51. nat_traversal - Dan Pascu
52. options - commonly maintained
53. osp - Di-Shi Sun, Dmitry Isakbayev
54. path - commonly maintained
55. pdt - commonly maintained
56. peering - commonly maintained
57. perl - Bastian Friedrich
58. perlvdb - Bastian Friedrich
59. permissions - commonly maintained
60. pike - Bogdan-Andrei Iancu
61. presence - Anca Vamanu
62. presence_dialoginfo - Anca Vamanu
63. presence_mwi - Anca Vamanu
64. presence_xcapdiff - Saúl Ibarra Corretgé
65. presence_xml - Anca Vamanu
66. pua - Anca Vamanu
67. pua_bla - Anca Vamanu
68. pua_dialoginfo - Anca Vamanu
69. pua_mi - Anca Vamanu
70. pua_usrloc - Anca Vamanu
71. pua_xmpp - Anca Vamanu
72. qos - Ovidiu Sas
73. ratelimit - Ovidiu Sas
74. regex - Iñaki Baz Castillo
75. registrar - Bogdan-Andrei Iancu
76. rls - Anca Vamanu
77. rr - Bogdan-Andrei Iancu
78. seas - Andrei Pisau
79. signaling - Anca Vamanu
80. siptrace - Bogdan-Andrei Iancu
81. sl - Bogdan-Andrei Iancu
82. sms - Bogdan-Andrei Iancu
83. snmpstats - Jeffrey Magder
84. speeddial - commonly maintained
85. sst - Ron Winacott
86. statistics - Bogdan-Andrei Iancu
87. textops - commonly maintained
88. tlsops - commonly maintained
89. tm - Bogdan-Andrei Iancu
90. uac - Bogdan-Andrei Iancu
91. uac_redirect - Bogdan-Andrei Iancu
92. uri - commonly maintained
93. uri_db - Sergio Gutierrez
94. uri_radius - commonly maintained
95. userblacklist - commonly maintained
96. usrloc - Bogdan-Andrei Iancu
97. xcap_client - Anca Vamanu
98. xlog - commonly maintained
99. xmpp - Anca Vamanu

Development -> Development

1. xmpp - Anca Vamanu

OpenSIPS 2.0 version releases

• First code release of OpenSIPS 2.0 is available for public. Take a look at the new design overview and also see the stage1 available features and how to download it.

• standard releases - will be supported up to the next release

Development -> Development

Release cycles

The release cycles is mainly time driven : a release each 5-7 months. depending on the required volume of work for the respective release

Smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade. Also, shorter release cycles will make new features available in stable versions much faster.

Next Release Planning

On a new cycle, we will start with a brainstorming on what the next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community ( see 1.9 example )

We will maintain a web page with the TODO features that will be updated (this process is to be continuous); also the items that where address to be documented and listed as new available features.

As the release is time driven, the next release will contain only the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release.

Steps inside a Cycle

• brainstorming on TODO list
• estimating the release time (T) based on the volume of work

(between 5-7 months)

• actual work on implementing the items on TODO list ; it is

critical important to have a better description / documentation / examples on the newly added feature,as this will help people to understand and use them from day 0 (an undocumented super feature is an inexistent feature)

• SVN freeze (no more new stuff) at T - 1 months ; at this point

the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release)

• this will make the trunk free and available for new work in the mean while (we overlap the testing on release N with the start of release N+1)

• testing, debugging - 1 month -> at T we have the GA release (full stable release)

Version Management

We will have two types of supported OpenSIPS stable 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

Such a model should maintain a decent balance between getting features out the door and support. 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.

New (2.0) design

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

Instead of a feature driven release cycle, we will have a time driven release cycle,because it is more predictable and being feature driven may actually escalate the time to the next release.

There will be a 5-7 months release cycle, depending on the required volume of work for the respective release

Following the 1.9 OpenSIPS release, the release policy has changed, in order to target making the release process :

• more open - anyone from community (and not only developers) should be able to contribute to the roadmap of the next release
• more predictable - everyone should know when and how the next release will be available, so they can rely and sync their own private schedules
• more transparent - the entire releasing process to be generally known in details, so we can achieve a better collaboration and interfacing between community and developer

• First code release of OpenSIPS 2.0 is available for public. Take a look at the http://www.opensips.org/Development/NewDesign? and also | http://www.opensips.org/Development/NewDesignStage1? available features.

• long term releases -
• short term releases - at any moment, officially we will support only the last 2 stable

release

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

• a complete new repository entry (probably GIT based) will be created for the new version (we need to keep the current trunk as testing ground for the 1.6 branch)
• the code already takes shape - once it will have a basic functionality (able to start, stop, create threads, cfg read, etc), we will upload the code on public repository.
• the first release of the 2.0 version is estimated to be done around beginning of 2011. Could be sooner or later, depending on challenges and support (man power) we will have.

Version Management ==================

     - at any moment, officially we will support only the last 2 stable 

release (by support I mean

         troubleshooting, fixing bugs, backporting, etc)
     - whatever is older than 2 stable release (like older than 1.7 now) 

is unsupported (no fixing,

         no packing, no new tarballs)
     - when a new release gets to a full stable state, the window of 2 

supported versions is shifted

         (like when 1.9 will become stable, 1.7 will become obsolete and 

unsupported).

• this will make the trunk free and available

for new work in the mean while (we overlap the testing on release N with the start of release N+1)

Steps inside a Cycle ====================

     - brainstorming on TODO list
     - estimating the release time (T) based on the volume of work 

     - actual work on implementing the items on TODO list ; it is 

critical important to have a

         better description / documentation / examples on the newly 

added feature -> it will help

         people to understand and use them from day 0 (an undocumented 

super feature is an

         inexistent feature)
     - SVN freeze (no more new stuff) at T - 1 months ; at this point 

the SVN trunk code

         is moved in a new separate SVN branch (dedicated to that 

release)-> Release Candidate

         (or beta release) ; this will make the trunk free and available 

for new work in the

         mean while (we overlap the testing on release N with the start 

     - testing, debugging - 1 month -> at T we have the GA release (full 

stable release)

development and roadmap of the project to the entire community ( see Main.Ver190? )

development and roadmap of the project to the entire community ( see http://www.opensips.org/Main/Ver190#toc15? )

be documented and listed as new available features (see http://www.opensips.org/Main/Ver190?)

development and roadmap of the project to the entire community ( see [ 1.9 example | http://www.opensips.org/Main/Ver190#toc15 ] )

 maintain a web page with the TODO features that will be updated 

http://www.opensips.org/Main/Ver190)

     - as the release is time driven, the next release will contain only 

Next Release TODO ==================

     - on a new cycle, we should start with a brainstorming on what the 

development and roadmap of the project to the entire community.

     - maintain a web page with the TODO features that will be updated 

• more predictable - everyone should know when and how the next release will be available
• more transparent - the entire releasing process to be generally known in details

Following the start of the work for OpenSIPS 2.0, the priorities and policies on releases changed.

Right now, most of development effort is invested in the version 2.0 code. What this means:

New (2.0) design

Old (existing) design

• there will be no more major release for this design - that's it, 1.6 is end of line
• bug fixes will be carried on as usual
• minor / essential improvements / adds-on will still be done on 1.6 branch
• minor releases on 1.6 branch will contain not only bug fixings, but also the improvements and adds-on ; actually 1.6 branch and trunk will contain the same code - trunk will be for coding and testing, 1.6 will be the stable - after a change/add-on is tested on trunk, it will be backported to 1.6 to be part of the next minor release.

New (2.0) design

Module maintainers

Release policy

Old (existing) design

Developers hierarchy