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é
<s...@ag-projects.com <mailto:s...@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@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
