Hi Mathieu, my suggestion, especially for these kinds of refactoring that affects the inner parts of the framework is to focus more on clean and simple design (and code) than over backward compatibility; a cleaner and smaller codebase is more manageable and will be better maintained by the community.
Thanks for all your efforts! Jacopo On Sat, Oct 19, 2019 at 6:32 PM Mathieu Lirzin <mathieu.lir...@nereide.fr> wrote: > 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 >
