<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hi Ali,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
<br>
On 11/25/2012 04:22 PM, Ali Pey wrote:
<blockquote
cite="mid:CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com"
type="cite">Hi Bogdan,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Again, this is a great step forward for opensips development
and thank you for the great work.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Ali Pey</div>
<div> </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Fri, Nov 23, 2012 at 4:36 AM, Saúl Ibarra Corretgé <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:saul@ag-projects.com" target="_blank">saul@ag-projects.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
> 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).<br>
> 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.<br>
><br>
> 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.<br>
><br>
<br>
</div>
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.<br>
<div class="im"><br>
><br>
> PS: let me ask you: how many OpenSIPS installations
do you still have running old versions because upgrade is
really painful ? ;)<br>
<br>
</div>
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.<br>
<br>
[snip]<br>
<div class="im"><br>
>> 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.<br>
> [bogdan]<br>
> That is true problem that may have as solutions:<br>
> 1) simply upgrade (most common way to go in open
source world) , considering that upgrades should become
easier.<br>
<br>
</div>
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.<br>
<div class="im"><br>
> 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....<br>
><br>
<br>
</div>
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.<br>
<br>
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 :-)<br>
<div class="im"><br>
<br>
Regards,<br>
<br>
--<br>
Saúl Ibarra Corretgé<br>
AG Projects<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
</div>
Users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a moz-do-not-send="true"
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</body>
</html>