<div>On Sun, Nov 25, 2012 at 10:32 AM, Brett Nemeroff <span dir="ltr"><<a href="mailto:brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"><div><br></div></div><div> Just my two cents here...</div><div><br></div><div>With regards to the release cycle... I typically find myself doing "production" 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't typically upgrade simply because an upgrade is available. Of course, I'll normally upgrade for critical fixes or security fixes (which I'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's new capabilities; but I wouldn'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'm afraid that time based releases may rush features out before they are ready.</div>
<div><br></div><div>That's just my perspective based on my workflow. I'm sure there are others that feel differently. :)</div><span class="HOEnZb"><font color="#888888"><div>-Brett</div></font></span></div></blockquote>
<div><br></div><div><br></div><div>I, for one, share Brett's perspective.</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div></div>