Development -> Development

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)

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.

to:

Release interval

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.

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.

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

actual work on implementing the items on TODO list ; docs must be realtime updated to reflect code changes

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 up to the next 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.

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

release

to:

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.

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:

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.

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 Management

We will have two types of supported OpenSIPS stable releases :

long term releases -

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

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.

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

to:

Steps inside a Cycle

brainstorming on TODO list

estimating the release time (T) based on the volume of work

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:

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

Release cycles

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

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

New (2.0) design

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.

Release policy

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:

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

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.

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:

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)

contributors - developers randomly contributing to OpenSIPS by providing patches (for fixes or new features). For how this works, see Contributing page.

packagers - people taking care of OpenSIPSpackaging (for different OS's) ; they are in-charge with maintaining the specs and preparing packages.