>On behalf of the entire R:BASE community and >Development Staff <snip>
> Another important issue to consider is that as the versions and builds > progress, we are doing our best to weed out all the inconsistencies > and improper behavior of prior versions. In using the older versions, > it is very common for a developer to use the logic of two "wrongs" to > make a "right." Now, we have to be reasonable when it comes to using > the new logic of two "rights" to make a "right." I have mixed feelings on this point. Using Tom's example, I suppose arguments could be made as to which form behavior is "right" (pre or post v1.851), but I don't think that is the issue. If, over the years, I've learned that certain aspects of RBase work in a particular way, I don't think it should be considered "wrong" to expect those characteristics to continue with subsequent releases. By the same token, if certain behaviors are not what RBTI intend and they want to make corrections, no problem. But I believe it's their responsibility to make those changes known to developers and users before they upgrade (let alone upgrade _their_ customers). It would just save everyone a lot of heartache. Ben Petersen a very small part of the RBase community ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
