From: "Conor MacNeill" <[EMAIL PROTECTED]> > I think you missed Bruce's point. Consider this scenario: > > You are given a build file. It uses some deprecated > features. You are asked to bring it up to date. If > the documentation doesn't specify what the deprecated > features do, how can you confidently make the changes.
If your build file is 1.2 compliant and you want to upgrade to 1.5, then, yes, you may have to read Ant 1.4.1's docs to see what got deprecated and removed (at least, from docs) in between. Otherwise, you would still be able to see the deprecated stuff visible in the docs. In fact, something along these lines was only suggested when the proposition to do away with deprecated code was brought up. What would the user have done to convert a build file from an old version to a new version which had deprecated code removed? - I guess the answer would be convert to the immediate next (or the 2nd next) version and then convert that once more (iteratively). > I agree with Bruce. Documentation should reflect > the code. If a feature is in the code, it should > be in the documentation. If a feature is deprecated > in the code, it should be marked as deprecated in > the documentation but it should still be described. OK, though I would like to somehow strongly discourage use of deprecated features... > > Conor Cheers, Magesh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
