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

[Bogdan-Andrei Iancu]

Hi Saul,

On 11/22/2012 12:46 PM, Saúl Ibarra Corretgé wrote:
>> 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.
>>
> While a time-based release cycle sounds good to me for minor releases (1.8.1, 1.8.2, ...) I'm not sure if it can also be applied to major releases. What if feature X takes longer than expected to develop? Things may be inadvertently rushed and that's not good. For major releases I'd go with the Debian-ish policy: it's ready when it's ready :-)
[bogdan]
The problem I see with the features-based release cycle is that they are 
unpredictable as time - some features may not be properly (or 
impossible) time evaluated -> it may stretch the interval between 
releases ; IMHO, for a project to reliable it is a must to be 
predictable. The best examples are what is happening now with OpenSIPS 
(the interval between releases is keep growing) and Debian (lack of 
predictability and huge intervals between release ended up in the Ubuntu 
alternative).
Being able to predict the releases (as time) without huge differences 
between versions (to make an upgrade something easy you are not scared 
like hell to do it) should be some key-feature of the project.

The time-based releases should not be affected by how long a feature 
takes to be implemented - 6 months of development for a feature is 
really more than enough, IMHO.


PS: let me ask you: how many OpenSIPS installations do you still have 
running old versions because upgrade is really painful ? ;)

>> 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).
>>
> What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not  a task to be taken lightly.
[bogdan]
That is true problem that may have as solutions:
     1) simply upgrade (most common way to go in open source world) , 
considering that upgrades should become easier.
     2) try to define what is really critical (based on what??) and 
still do backporting - but at the end of the day we need to encourage 
people to use the new versions - keep patching and supporting really old 
versions (consider 1.6 at this point) is a waist of effort. Taking your 
example: debian is not supporting something older than 1 release :D....

But I'm open to solutions here.

Regards,
Bogdan