Hello, In my recent work on refactoring ‘Container’ and ‘ContainerConfig’ classes (See trunk) I have chosen (without discussing on ML) to use deprecation for stuff that were likely to be used by client code implementing additional containers in their plugins.
However I have just discovered that in 2016 some refactoring work chose a different approach by simply changing a method signature in the ‘ContainerConfig’ interface [1]. Having @Deprecated methods is a tradeoff that provides smoother migration path for client code with the cost of cluttering our codebase which make things harder to maintain. So I would like to know what are the general expectations of people developing OFBiz plugins in term of backward compatibility and what people would recommend as a general guideline regarding “modifying public Java interfaces”. What do people think? [1] https://github.com/apache/ofbiz-framework/commit/d44020f0d6b2af4c049722751e4586a3ae5b2d98#diff-af4722454ae770d57420936da9bd4e29L55-R56 -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
