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

[Bogdan-Andrei Iancu]

Hi Saul,

On 11/23/2012 11:36 AM, Saúl Ibarra Corretgé wrote:
> Hi,
>
>> 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.
>>
> I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.
[bogdan]
copying from another answer of mine: Keep in mind that all the time a 
new release will be a set of new features, so basically all releases are 
also featured driven. But to make it more predictable, we consider some 
time limits (for a release cycle) - limits are quite large 5 to 7 
months, so we have flexibility to fit various sets of features in that 
interval. The main idea with time-based cycles is to try to control how 
long will take for have the next release (more predictable, without 
large gaps between releases) and also to speed up the features delivery 
(having a faster cycle, features will be available in stable versions 
quicker).
>
> 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.
> New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.
>
>>     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....
>>
> Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.
>
> We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)
[bogdan]
again, copying from another answer of mine: I have to admit I didn't do 
the math - 2 release ~= 1 year, which indeed is too short - I mean this 
will force an upgrade each year. So, we need to somehow get to ~ 2 year 
lifetime for a release. My suggestion is to actually set a life span for 
2 years.


Regards,
Bogdan