<div><br></div>On Thu, Nov 22, 2012 at 4:34 AM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<u></u>

  

    
  
  <div bgcolor="#ffffff" text="#000000"><tt><br>
      Release cycles<br>
      ===============<br>
          - instead of a feature driven release cycle, I would prefer a
      time driven release cycle - because it is more predictable and
      being feature driven may actually escalate the time to the next
      release (the snowball effect) - see the timing for 1.7, 1.8
      versions<br>
          - have a 5-7 months release cycle (depending on the required
      volume of work)<br>
          - smaller steps in releases will be more friendly to users as
      there are no big gaps between releases, easier and more appealing
      to upgrade ; also shorter release cycles will make new features
      available in stable versions much faster.<br><br></tt></div></blockquote><div><br></div><div><br></div><div> Just my two cents here...</div><div><br></div><div>With regards to the release cycle... I typically find myself doing &quot;production&quot; deployments for my clients. What I need is a stable version. And then hotfixes as bugs are discovered. </div>

<div><br></div><div>I prefer feature driven releases because I can look forward to when feature X will be available. My production deployments typically run untouched while in production mode. Upgrades occur when new features are needed AND available in stable builds. I don&#39;t typically upgrade simply because an upgrade is available. Of course, I&#39;ll normally upgrade for critical fixes or security fixes (which I&#39;d see as a hotfix typically and not a full release)</div>

<div><br></div><div>If I knew a release was going to be available on a particular date, I would without question start reviewing that release and it&#39;s new capabilities; but I wouldn&#39;t need it for a production build. </div>

<div><br></div><div>If I knew a feature was available on a certain date, I could pitch that to my clients if it was a feature they might need. Also, I&#39;m afraid that time based releases may rush features out before they are ready.</div>

<div><br></div><div>That&#39;s just my perspective based on my workflow. I&#39;m sure there are others that feel differently. :)</div><div>-Brett</div><div><br></div><div><br></div></div>