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

[Bogdan-Andrei Iancu]

Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul 
raised the same point as you, and 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-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/25/2012 04:22 PM, Ali Pey wrote:
> Hi Bogdan,
>
> This is great to see and I quite like the more open, predictable and 
> transparent approach. I also agree that a time driven release cycle is 
> more practical than feature driven. There are always grey areas and 
> exceptions but in practice a time driven release cycle is much better 
> manageable for real world deployments.
>
> In terms of support for previous releases, as much as it would allow a 
> deployment to go on for two years before it requires an upgrade I 
> agree. It's not practical to have more frequent upgrade cycles. Also 
> most people don't usually upgrade to the latest version. For instance 
> when 1.9 comes out, we probably will upgrade to 1.8.2.
>
> Again, this is a great step forward for opensips development and thank 
> you for the great work.
>
> Regards,
> Ali Pey
>
>
> On Fri, Nov 23, 2012 at 4:36 AM, Saúl Ibarra Corretgé 
> <saul at ag-projects.com <mailto:saul at ag-projects.com>> 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.
>
>     >
>     > 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
>
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121126/cc61ded1/attachment.htm>