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

[Saúl Ibarra Corretgé]

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.

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

Fortunately not many :-) I had to migrate from 1.4 to 1.8 and, well, things can get complicated. Of course the gap is big and wouldn't be so big between 1.7 and 1.8 or between 1.8 and 1.9, but updating requires time and a reason. If a customer has a working OpenSIPS version and I update it just for the sake of it, new bugs can be introduced, and he'll probably not see any of the new features because he doesn't need them, for example. This is what I mean by not taking it lightly.

[snip]

>> 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 :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects