[OpenSIPS-Users] [RFC] New Release Policy for OpenSIPS project

[Bogdan-Andrei Iancu]

Hi all,

I want to bring to public discussion the changing of the release policy 
of the project. Why, because I had an interesting feedback from the 
community after the email on shaping the 1.9 release and I felt the need 
of straighting some things up.

First of all, what this change should target? It should make the release 
process :
     - *more open* - anyone from community (and not only developers) 
should be able to
         contribute to roadmap of the next release (on what should be done)
     - *more predictable* - everyone should know when and how the next 
release will be
         available, so they can rely and sync their own private 
schedules (for using opensips)
         with the project scheduling. You will know when the next 
release will be available
         as RC, as GA, etc, you will know what features will contain, 
you will know when to
         get involved for bringing in discussion some new features for 
the next release.
     - *more transparent* - the entire releasing process to be generally 
known in details, so
         we can achieve a better collaboration and interfacing between 
community and developers
         (we should avoid a separation between these two entities and 
rather put them together
         to work)


Now, I'm listing here what I see as a starting point and I'm eager to 
hear your comments, suggestions, improvements or any other ideas related 
to this topic.

Release cycles
===============
     - instead of a feature driven release cycle, I would prefer a time 
driven release cycle - because it is more predictable and being feature 
driven may actually escalate the time to the next release (the snowball 
effect) - see the timing for 1.7, 1.8 versions
     - have a 5-7 months release cycle (depending on the required volume 
of work)
     - 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).



Regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121122/743378d0/attachment.htm>