On 4/26/06, Jorge Godoy <[EMAIL PROTECTED]> wrote: > > Em Quarta 26 Abril 2006 09:59, Tim Lesher escreveu: > > > > If it changes such that upgrading silently breaks my app in a subtle > > way that pre-deployment testing doesn't detect, and then causes me to > > have to explain to a CFO at 8:30 AM why we can't bill for anything in > > the past three months, why, yes, I'd rather have worked around a > > missing feature. > > > > Yes, this has happened to me. (Curse you, Sybase!) :-) > > I am just wondering *why* would you upgrade at 8h30 at the deployment day > after running all your test suite and doing integration tests and > functionality checks with the older version. > > Documented or not, you still have to test (the several kinds of tests) your > application. Develop against a moving target isn't easy. >
Actually, what happened is that we had a known, unrelated issue with our Sybase DB. Sybase gave us an update to fix the issue. We testing it hard for a week (including all our scripts, and with copies of "live" data), saw no issues, and deployed it. Problem fixed. Three months later, an end-of-month "rollup" script which we wrote using a Sybase scripting language broke in unexpected and subtle ways, writing slightly-munged data into the billing system. It wasn't obviously wrong, but just enough that the CFO noticed unusual bills about to be sent to customers and pressed the "panic button". The problem was that the scripting language compiler changed an obscure detail of how object attributes got resolved. It was dependent on what code had run on the script server _just before_ an object was instantiated. Our tests still succeeded, and the rollup script worked fine for the first two months that it ran. The language was based on ECMAScript and most of Sybase's docs just pointed to the ECMA specification--even though the implementation didn't do what the spec said. So most of what we knew about it was by trial and error. Sybase's response was "No, it's not a bug; we just don't implement that part of the spec. We'll change the documentation in the next release." > Also, if you need some specific fix, you can grab it from TG's repository: > this is one of the best things about open source. Absolutely. For example, if we'd had source for the scripting engine in the above case, we would have known ahead of time that what we were doing only worked by chance. Right now, I'm working on an in-house project that will only be used by our developers and isn't on the critical path for our software releases, so I'm comfortable with alpha releases, pulling patches from Trac, etc. If I were working on something more mission-critical, I'd be using TG 0.8, and widgets be damned. :-) I just wanted to make the point that an implemented-but-undocumented feature isn't _always_ better than not having the feature at all. Some people (like me right now) would rather have the feature; others (like me on the Sybase project) would rather have the documentation. -- Tim Lesher <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
