<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite"><span style="font-family: Arial, Helvetica,
        sans-serif; font-size: 10pt"> I like the idea of LTR release
        more often that would have the feature patches baked in.&nbsp; 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.&nbsp;</span></blockquote>
    <br>
    Well said!&nbsp; This is also true of any type of long term supported
    release whether if it's an operating system, application, etc.&nbsp; 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). <br>
    <br>
    Red Hat works so well for server systems because features are
    regularly backported with a *huge* emphasis on never breaking abi or
    build environments.&nbsp; 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.<br>
    <br>
    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".&nbsp;&nbsp; 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.<br>
    <br>
    It should also be said that the long term release really isn't the
    appropriate place to debut new technology.&nbsp; If you absolutely
    require the newest stuff that Digium produces, regardless of their
    LTS paradigm, the LTS release probably isn't meant for you.&nbsp; Using
    the RHEL/Fedora example of earlier, RHEL's backports only come
    through around once a year during the point releases.&nbsp; Anything more
    would be chaotic and against the notions of a long term supported
    release.&nbsp; Fedora gets new stuff every 6 months, freshly baked with
    some stuff just not working all that well.&nbsp; <br>
    <br>
    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.&nbsp; 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.<br>
    <br>
    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. &nbsp; <br>
    <br>
    But think back before 1.8.x and Digium's plan for LTS:&nbsp; 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.&nbsp; 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. <br>
    <br>
    Personally, I don't think what Digium is doing is necessarily a
    perfect approach (hey, what is?&nbsp; we're all human), but they've
    vastly improved the quality of Asterisk from a support perspective.&nbsp;
    <br>
    <br>
    <div class="moz-signature">
      <p><img src="cid:part1.07010005.06080204@classiccitytelco.com"></p>
      <p>
        <b>John Knight</b><br>
        Classic City Telco LLC<br>
        <b>Email:</b> <a class="moz-txt-link-abbreviated" href="mailto:john@classiccitytelco.com">john@classiccitytelco.com</a> <b>|</b> <b>Main:</b>
        (706) 995-0200<br>
        <b>Direct:</b> (706) 995-0201 <b>|</b> <b>Mobile:</b> (706)
        255-9203</p>
    </div>
    <br>
    On 1/31/2012 2:20 PM, Bryant Zimmerman wrote:
    <blockquote cite="mid:4d4848cf$68b36552$5e06abed$@com" type="cite"><span
        style="font-family: Arial, Helvetica, sans-serif; font-size:
        10pt">From my perspective this makes a lot more sense than the
        current cycle. My big issue is with&nbsp;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.&nbsp; 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.&nbsp; This new method would reduce
        the time for situations like this.&nbsp; This is the same with the F
        option in faxReceive as well. <br>
        <br>
        <div>Thanks<br>
          <br>
          Bryant&nbsp;Zimmerman (ZK Tech Inc.)<br>
          616-855-1030 Ext. 2003</div>
        <br>
        <br>
        <span style="font-family: tahoma,arial,sans-serif; font-size:
          10pt;">
          <hr align="center" size="2" width="100%">
          <b>From</b>: "Kevin P. Fleming" <a class="moz-txt-link-rfc2396E" href="mailto:kpfleming@digium.com">&lt;kpfleming@digium.com&gt;</a><br>
          <b>Sent</b>: Tuesday, January 31, 2012 12:36 PM<br>
          <b>To</b>: "Asterisk Users Mailing List - Non-Commercial
          Discussion" <a class="moz-txt-link-rfc2396E" href="mailto:asterisk-users@lists.digium.com">&lt;asterisk-users@lists.digium.com&gt;</a><br>
          <b>Subject</b>: [asterisk-users] Proposed changes to Asterisk
          release and support cycles</span><br>
        <br>
        I've created a page on wiki.asterisk.org outlining some changes
        we're <br>
        proposing to make to the Asterisk release and support cycles. As
        always, <br>
        before implementing any changes of this type, we'd like to
        collect some <br>
        community feedback on the proposal.<br>
        <br>
        The page is here:<br>
        <a class="moz-txt-link-freetext" href="https://wiki.asterisk.org/wiki/x/5ggiAQ">https://wiki.asterisk.org/wiki/x/5ggiAQ</a><br>
        <br>
        Feel free to comment here, or on the page itself if you find any
        errors <br>
        or inconsistencies in the page's content.<br>
        <br>
        -- <br>
        Kevin P. Fleming<br>
        Digium, Inc. | Director of Software Technologies<br>
        Jabber: <a class="moz-txt-link-abbreviated" href="mailto:kfleming@digium.com">kfleming@digium.com</a> | SIP: <a class="moz-txt-link-abbreviated" href="mailto:kpfleming@digium.com">kpfleming@digium.com</a> | Skype:
        kpfleming<br>
        445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
        Check us out at <a class="moz-txt-link-abbreviated" href="http://www.digium.com">www.digium.com</a> &amp; <a class="moz-txt-link-abbreviated" href="http://www.asterisk.org">www.asterisk.org</a><br>
        <br>
        --<br>
_____________________________________________________________________<br>
        -- Bandwidth and Colocation Provided by
        <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --<br>
        New to Asterisk? Join us for a live introductory webinar every
        Thurs:<br>
        <a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a><br>
        <br>
        asterisk-users mailing list<br>
        To UNSUBSCRIBE or update options visit:<br>
        <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
        <br>
      </span>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
New to Asterisk? Join us for a live introductory webinar every Thurs:
               <a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a></pre>
    </blockquote>
  </body>
</html>