Development |
Development.Development HistoryHide minor edits - Show changes to markup November 06, 2020, at 05:19 PM
by
- Changed line 31 from:
to:
November 06, 2020, at 05:19 PM
by
- Changed line 31 from:
to:
November 05, 2020, at 08:40 PM
by
- Changed line 29 from:
to:
Changed line 35 from:
to:
November 05, 2020, at 08:35 PM
by
- Changed line 25 from:
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: to:
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: November 05, 2020, at 08:35 PM
by
- Changed line 23 from:
Types of OpenSIPS Major Releasesto:
Major Release FlavorsNovember 05, 2020, at 08:34 PM
by
- Changed lines 23-25 from:
OpenSIPS Version ManagementFrom a maintenance point of view, there are two types of major releases: to:
Types of OpenSIPS Major ReleasesThe type of a release affects both its content (choice of features), as well as its maintenance timeline. There are two types of major releases: November 05, 2020, at 08:30 PM
by
- Added line 28:
Changed lines 32-33 from:
to:
Added line 34:
Deleted line 37:
November 05, 2020, at 08:29 PM
by
- Changed line 45 from:
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. to:
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. November 05, 2020, at 08:29 PM
by
- Added lines 43-44:
Added lines 46-47:
\\ November 05, 2020, at 08:29 PM
by
- Changed line 41 from:
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. to:
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. November 05, 2020, at 08:28 PM
by
- Changed line 41 from:
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. to:
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. November 05, 2020, at 08:27 PM
by
- Changed line 41 from:
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. to:
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. November 05, 2020, at 08:26 PM
by
- Changed line 35 from:
to:
November 05, 2020, at 08:24 PM
by
- Changed line 36 from:
to:
November 05, 2020, at 08:24 PM
by
- Changed line 36 from:
to:
November 05, 2020, at 08:23 PM
by
- Changed line 36 from:
to:
November 05, 2020, at 08:22 PM
by
- Changed line 36 from:
to:
November 05, 2020, at 08:21 PM
by
- Changed line 28 from:
to:
Changed line 34 from:
to:
November 05, 2020, at 08:20 PM
by
- Changed lines 4-12 from:
Release policyOpenSIPS 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).
to:
OpenSIPS Release PolicyThe 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).
Changed lines 17-18 from:
to:
Changed lines 20-21 from:
to:
Changed lines 23-36 from:
Version ManagementFrom maintenances point of, there are two types of releases.
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. to:
OpenSIPS Version ManagementFrom a maintenance point of view, there are two types of major releases: Standard Releases
Long-Term Supported Releases (LTS)
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. March 01, 2019, at 02:38 PM
by
- Changed line 14 from:
to:
March 01, 2019, at 02:37 PM
by
- Changed line 14 from:
to:
December 13, 2018, at 04:37 PM
by
- Changed lines 10-11 from:
to:
Deleted line 14:
Changed line 16 from:
to:
December 13, 2018, at 04:34 PM
by
- Deleted lines 1-2:
(:toc-float Table of Content:) December 13, 2018, at 04:34 PM
by
- Deleted lines 36-152:
OpenSIPS Experimental
Developers hierarchyTo ensure the quality and technical competence across the project, the development work is governed by developer knowledge.
Module maintainers
September 17, 2018, at 02:25 PM
by
- Changed line 1 from:
Development -> Developmentto:
April 11, 2017, at 05:37 PM
by - April 11, 2017, at 05:35 PM
by - April 11, 2017, at 05:34 PM
by
- Changed line 153 from:
to:
April 11, 2017, at 05:31 PM
by - October 10, 2014, at 03:40 PM
by
- Changed lines 39-41 from:
OpenSIPS 2.0 version releases
to:
OpenSIPS Experimental
August 07, 2013, at 12:34 AM
by
- Changed line 27 from:
to:
May 14, 2013, at 02:00 PM
by
- Changed line 1 from:
Development -> Developmentto:
Development -> DevelopmentJanuary 18, 2013, at 03:42 PM
by
- Added line 22:
January 18, 2013, at 03:42 PM
by
- Changed lines 10-52 from:
Release cyclesThe 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 PlanningOn 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
(between 5-7 months)
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)
the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release)
Version ManagementWe will have two types of supported OpenSIPS stable releases :
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. to:
Version ManagementFrom maintenances point of, there are two types of releases.
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. Changed line 38 from:
New (2.0) designto:
OpenSIPS 2.0 version releasesJanuary 18, 2013, at 03:07 PM
by
- Changed lines 8-9 from:
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). to:
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). Changed lines 12-14 from:
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 to:
The release cycles is mainly time driven : a release each 5-7 months. depending on the required volume of work for the respective release January 18, 2013, at 02:59 PM
by
- Changed lines 8-11 from:
Following the 1.9 OpenSIPS release, the release policy has changed, in order to target making the release process :
to:
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). January 17, 2013, at 05:21 PM
by
- Added lines 61-62:
January 17, 2013, at 05:02 PM
by
- Changed line 64 from:
to:
January 17, 2013, at 05:01 PM
by
- Changed lines 53-56 from:
release to:
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. Changed lines 60-61 from:
Once an OpenSIPS releases moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs. to:
Once an OpenSIPS release moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs. Changed lines 63-68 from:
to:
January 17, 2013, at 04:48 PM
by
- Changed lines 50-62 from:
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). to:
Version ManagementWe will have two types of supported OpenSIPS stable releases :
release 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 releases moves to unsupported status, it will not get any new bug fixes, any packaging or new tarballs. January 17, 2013, at 04:42 PM
by
- Changed lines 47-49 from:
for new work in the mean while (we overlap the testing on release N with the start of release N+1) to:
January 17, 2013, at 04:42 PM
by
- Changed lines 35-38 from:
Steps inside a Cycle ==================== - brainstorming on TODO list - estimating the release time (T) based on the volume of work to:
Steps inside a Cycle
Changed lines 40-53 from:
- 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 to:
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)
the SVN trunk code is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate (or beta release)
for new work in the mean while (we overlap the testing on release N with the start Changed lines 50-51 from:
- testing, debugging - 1 month -> at T we have the GA release (full stable release) to:
January 17, 2013, at 04:40 PM
by
- Changed line 25 from:
development and roadmap of the project to the entire community ( see Main.Ver190? ) to:
development and roadmap of the project to the entire community ( see 1.9 example ) January 17, 2013, at 04:39 PM
by
- Changed lines 25-26 from:
development and roadmap of the project to the entire community ( see http://www.opensips.org/Main/Ver190#toc15? ) to:
development and roadmap of the project to the entire community ( see Main.Ver190? ) Changed lines 29-31 from:
be documented and listed as new available features (see http://www.opensips.org/Main/Ver190?) to:
be documented and listed as new available features. January 17, 2013, at 04:37 PM
by
- Changed lines 25-27 from:
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 to:
development and roadmap of the project to the entire community ( see http://www.opensips.org/Main/Ver190#toc15? ) We will maintain a web page with the TODO features that will be updated Changed lines 30-31 from:
http://www.opensips.org/Main/Ver190) - as the release is time driven, the next release will contain only to:
http://www.opensips.org/Main/Ver190?) As the release is time driven, the next release will contain only January 17, 2013, at 04:35 PM
by
- Changed lines 21-23 from:
Next Release TODO ================== - on a new cycle, we should start with a brainstorming on what the to:
Next Release PlanningOn a new cycle, we will start with a brainstorming on what the Changed lines 25-26 from:
development and roadmap of the project to the entire community. - maintain a web page with the TODO features that will be updated to:
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 January 17, 2013, at 04:34 PM
by
- Added lines 12-69:
Release cyclesInstead 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 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 TODO ================== - on a new cycle, we should 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. - 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 (see http://www.opensips.org/Main/Ver190) - 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 -> 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 of release N+1) - testing, debugging - 1 month -> at T we have the GA release (full stable release) 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). January 17, 2013, at 04:01 PM
by
- Changed lines 10-11 from:
to:
January 17, 2013, at 04:00 PM
by
- Changed lines 8-11 from:
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: to:
Following the 1.9 OpenSIPS release, the release policy has changed, in order to target making the release process :
January 17, 2013, at 03:50 PM
by
- Changed line 13 from:
New (2.0) designto:
New (2.0) designJanuary 17, 2013, at 03:50 PM
by
- Changed lines 13-23 from:
Old (existing) design
New (2.0) designto:
New (2.0) designJanuary 17, 2013, at 03:49 PM
by
- Changed line 43 from:
Module maintainersto:
Module maintainersJanuary 17, 2013, at 03:49 PM
by
- Added lines 3-4:
(:toc-float Table of Content:) Changed lines 6-7 from:
Release policyto:
Release policyChanged lines 13-14 from:
Old (existing) designto:
Old (existing) designChanged line 32 from:
Developers hierarchyto:
Developers hierarchy |