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

[Ali Pey]

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>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
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121125/dcb4b805/attachment.htm>