The problem with this is that if 1.2 has a bug that is making it unstable, it should be fixed to make a stable project, rather then steam rolling ahead to the next release. Further, I have seen on several occassions a security patch cause stability issues in Asterisk.
On 5/30/07, Jared Smith <[EMAIL PROTECTED]> wrote:
On 5/30/07, Steve Totaro <[EMAIL PROTECTED]> wrote: > I do hope that when they find major security bugs like the recent SIP > bug for example, that affected both 1.2.x and 1.4.x, they backport the > fix. At least if the code base has not changed all that much and it is > only a few lines of code. Yes, that's the whole idea of putting Asterisk 1.2 into "Security Maintenance Mode" (or whatever the official name is for it). Security issues will still be fixed for 1.2.x releases, but non-security-related bug fixes will only be applied to the 1.4 branch and trunk. I would anticipate that security issues will continue to be fixed until the next branch (1.6?) is released, and enough time has elapsed until 1.4 is put into security mode as well. The idea is that at any given time, you'll have: Trunk -- new features + bug fixes + security fixes Current release branch -- bug fixes + security fixes, but no new features Previous release branch -- security fixes only (after ~6 months from the date that the current release branch is released). Just to clarify, we currently have: Trunk -- new features + bug fixes + security fixes 1.4 -- bug fixes + security fixes, but no new features 1.2 -- security fixes only When 1.6 is released we'll have: Trunk -- new features + bug fixes + security fixes 1.6 -- bug fixes + security fixes, but no new features 1.4 -- bug fixes + security fixes, but no new features and about six months after 1.6 is released, we'll have: Trunk -- new features + bug fixes + security fixes 1.6 -- bug fixes + security fixes, but no new features 1.4 security fixes only The idea is to give everyone a reasonable amount of time to migrate their systems, after a new release branch is released. I think everyone realizes that a new release branch isn't automagically perfect, and it takes a little time to shake out the bugs. If you're still having problems with the 1.4 branch (or with specific versions of the 1.2 branch), I suggest you do the following to help the developers track down the problems: 1) Check to see if there are any other bug reports with the same symptoms as your own. 2) If there aren't any, fill out your own bug report. Please include as much pertinant information as possible. Does the problem only occur during high call volumes? Is it repeatable? Was a core file generated? If so, please provide a backtrace. 3) Please work with the bug marshalls and developers as they request feedback in the bug tracker. Unfortunately, we have a high number of bugs where someone reports a bug, but doesn't give any additional information when requested. 4) Try any suggested patches. I know this is difficult for some people (especially those who are running Asterisk in production systems, and don't have a test environment setup). Unfortunately, the developers can't fix the bugs without your help. -Jared _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
