On Apr 9, 2007, at 9:53 PM, [EMAIL PROTECTED] wrote: > I hate to contribute to this thread,
ditto, but hey, this dead horse looks like it could use another beating :-/ > but I don't think this is > completely accurate. In the old days, releases were a LONG time apart > -- sometimes over a year. This actually had the side benefit that the platform was given time to "stabilize", with maintenance releases (.1, .2, etc) that were sometimes released just weeks after the major release. > As a result, whenever a release came out, > there was immediately a loud whine-fest from anyone whose favorite > feature didn't make it into the release. > <snip/> > The 90-days-or-less cycle, on the other hand, has the great benefit > that the releases are smaller and more frequent, so if your pet > feature > doesn't make it in, you don't have so long to wait. However, there is NEVER a release that just fixes bugs. invariably the new features added with each release seem to somehow touch and break something that has been working just fine since the beginning of time. > I, for example, > submitted a feature request for the EditField to support tab stops on > all platforms, just a few days before R2 was released. It didn't make > it into R2, of course, but it did get marked as fixed for R3. I'm > content, because I know that I'll get to use this feature within a few > months at most. On the other hand, we discovered right after the release of r1 that number formatting was broken, we were in beta, and the bug only showed up on the windows platform. We filed a bug report, and received a response within a couple of hours that the bug was not only verified, but it was fixed. Now, this formatting bug caused a problem with the sending of numbers via the built in SOAP classes (pretty much the entire whole of our program), so, at this point we were stuck. It was less than a week after the release of r1, and a very simple but catastrophic bug had been fixed for the next release, but we wouldn't see it for 90 days. > As others have noted, it really doesn't matter what RS does; > there will be a long opinionated thread such as this one after each > release. True, but in this case, it would be nice to get an outward sign from RS that our quality concerns are being heard and addressed (see my suggestion below). > I just wish it would move over to the forum, leaving this > mailing list for productive discussions! Well, I think if this thread draws the attention of someone at RS who can address or at least reassure us on our quality concerns, then it would be productive. The point release benefitted from having interim releases, while the new RR program benefits from more frequent releases. I for one would really like to have a combination of the two release programs. Keep the rapid release schedule, but at the same time, add a point (bug fix / maintenance) release at 30 days and if needed 60 days, to give the platform a chance to "settle down". If it turns out that there are no bugs in the regular 90 day release then obviously the interim builds would be unnecessary. You know the old adage "never adopt a .0 release", well at this point, that's all RB provides. Sorry for wasting everyone's bandwidth -jason _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
