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