IMO, for each of these public classes/methods/fields that we are fixing for typos, we should mark them @Deprecated (and add a @deprecated javadoc too and point to the new field/method/class) and introduce the rightly named class/method/field. For methods it’s straightforward, the deprecated method internally calls the new method. For fields too it’s straightforward. The deprecated field uses the value of the new field. For classes, I think we can copy over the existing class into the new one and leave around the existing one just for possible external references (that we can’t control off) and migrate all internal references to the new one.
At some point, in some future version of Ivy, we remove/delete these deprecated method/field/class. -Jaikiran On 29-May-2017, at 1:43 PM, Jan Matèrne <j...@materne.de> wrote: I did a review of <https://github.com/apache/ant-ivy/pull/33> https://github.com/apache/ant-ivy/pull/33 Here are the points I have problems with, so I want to discuss them here. Basically it's about breaking BC. So how to deal with that? Jan Fixing the spell error in DelegateHandler$ChildElementHandler (s/childHanlded/childHandled/) means breaking beakward compatiblity. We could introduce a delegetate for that: /** for BC */ @Deprecated public void childHanlded(DH child) throws SAXParseException { childHandled(DH child); } While refactoring you have renamed all occurences in the Ivy codebase. On the other hand I don't know the impact (maybe outside of Ivy). I'll bring that to the dev-list. src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the public constant DEFAULT_BUNLDE_FILTER also means breaking BC. src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes the (IMO unneccessary) ParseException. But because it is a checked Exception we break BC. renaming EncrytedProperties to EncryptedProperties means breaking BC. If required we could introduce a delegating class or a subclass. ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If required we could introduce a delegating method. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
