Hi Saul,
On 11/23/2012 11:36 AM, Saúl Ibarra Corretgé 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.
[bogdan]
copying from another answer of mine: Keep in mind that all the time a
new release will be a set of new features, so basically all releases are
also featured driven. But to make it more predictable, we consider some
time limits (for a release cycle) - limits are quite large 5 to 7
months, so we have flexibility to fit various sets of features in that
interval. The main idea with time-based cycles is to try to control how
long will take for have the next release (more predictable, without
large gaps between releases) and also to speed up the features delivery
(having a faster cycle, features will be available in stable versions
quicker).
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 :-)
[bogdan]
again, copying from another answer of mine: 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
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
