I like the idea of LTR release more often that would have the feature patches baked in. Case in point the new conference app requires a jump to version 10 while the 1.8 conference app is quite useless but 1.8 is my LTR version so I am stuck without the conference app in my mainline systems for two years. Well said! This is also true of any type of long term supported release whether if it's an operating system, application, etc. In the "LTS" name, it conjurs up thoughts of Ubuntu, but comparisons to RHEL/Fedora are far more appropriate I would think as Ubuntu focuses nearly exclusively on new point releases while backporting new features is what a company like Red Hat excels at and should be the prime example of how to run dual software channels (enterprise release in RHEL vs. hobby release in Fedora). Red Hat works so well for server systems because features are regularly backported with a *huge* emphasis on never breaking abi or build environments. So far there really hasn't been a lot of noticeable features backported to 1.8.x that I'm aware of, but then again 10 is the first release after 1.8. Generally, if there isn't a lot of support in maintaining a long term release, then it turns into merely a "old release that occasionally has quality security updates". This is a perfectly valid approach too, but so far Digium's use of "LTS" doesn't really clarify clearly to me which type they are meaning to confer: 1) release that will stay static for its entire release sans security updates or 2) release that will stay compatible throughout the software's life time while occasionally having features backported with development funded from paying clients with support contracts. It should also be said that the long term release really isn't the appropriate place to debut new technology. If you absolutely require the newest stuff that Digium produces, regardless of their LTS paradigm, the LTS release probably isn't meant for you. Using the RHEL/Fedora example of earlier, RHEL's backports only come through around once a year during the point releases. Anything more would be chaotic and against the notions of a long term supported release. Fedora gets new stuff every 6 months, freshly baked with some stuff just not working all that well. I know distros and applications are two fundamentally different things, with entirely different goals and requirements, but I still think Red Hat provides the best example because 1) they have turned it into a science how smooth their development process goes in ratio to satisfied customers and 2) it's the only other open source software project I can think of that can accurately compare. In a past meeting I had with Digium while working for another company, they too directly drew a correlation between the new LTS idea and ubuntu lts/non-lts and rhel/fedora. The conference app changes since 1.4 I haven't been thrilled with, but in the whole time I've been supporting 1.8.x for my customers, I've come up with a very stable solution building on it and I haven't had any surprises come my way. But think back before 1.8.x and Digium's plan for LTS: We lived in a world where 1.4 bounced back and forth between "ultra-stable" and "whoops, dtmf is completely borked again" largely due to the fact that a complete rewrite of various parts of Asterisk would greatly undermine projects written specifically for that branch so small fixes netted breakage in other parts of the software. And we also had 1.6.x which for 95% of stuff was brilliant, but that other 5% was so crucial that it delayed adoption. Personally, I don't think what Digium is doing is necessarily a perfect approach (hey, what is? we're all human), but they've vastly improved the quality of Asterisk from a support perspective.
John Knight On 1/31/2012 2:20 PM, Bryant Zimmerman wrote: From my perspective this makes a lot more sense than the current cycle. My big issue is with patches that have new features. Not having them in a trunk released version adds a lot of issues trying to support them in house. I like the idea of LTR release more often that would have the feature patches baked in. Case in point the new conference app requires a jump to version 10 while the 1.8 conference app is quite useless but 1.8 is my LTR version so I am stuck without the conference app in my mainline systems for two years. This new method would reduce the time for situations like this. This is the same with the F option in faxReceive as well. |
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
