There are lots of things that are inconsistent & due to backwards compatibility. No, we dont want to change them.
Fair enough, I can relate to that. And as Mr Fernandez points out, there may be a better solution anyway in this particular case.
do you want to field every bug report that comes in saying we broke their build?
Touchy, aren't we?
No, though I am a bit grumpy with telcos this morning; the subject of DSL provisioning is a sensititive one today.
asking if you wanted to field the calls was a serious question -any change to the runtime's semantics will result in many bugreps, and someone will have to deal with theim.
No, not particularly. Sometimes though, some things may hurt enough that backward compatibility is sacrificed, which I just wanted to hear some opinions on, with, I hope, a courteous and simple query. I'm sorry if I offended you.
I'm not offended; its quite often that people want to fix the inconsistencies. The problem is that we are fairly confined by what we change.
The worst changes are those that make it impossible to write a build file that works consistent on both versions of ant, yet appears to work on both versions. Adding a new task or type clearly wont run on an old version, but changing a default is the kind of subtle change that doesn't appear to break things, but changes the expected results. People really hate it when we do that.
includeAntRuntime is clearly one of those legacy hacks. Originally the ant runtime was always included; the addition of a switch to turn it off was the new feature...to keep the old builds working the switch was off by default. Similarly, the <exec> and <java> tasks have failonerror=false as default, nearly everything else has it set to true, because those two tasks predate the failonerror pattern.
Eventually backwards compatibility will box us into a state where it becomes impossible to make progress or write good build files. This is why so much discussion goes into the merits of new features (like namespaces), because if we get it wrong then it will make everything wrong down the line. If there was too much focus on the immediate solution we'd end up with something like Win32 API, rather than something more consistent (like the Unix API).
Thank you anyway,
ken1
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
