This is an issue to discuss backwards-compatibility models. Suggestions could be for example (maybe someone knows about a cool model from somewhere)
- No backwards-compatibilty, only deprecate if feasible/simple -> required good changelog+descriptions+commit history+error messages
- Partial backwards-compatibilty: declare some classes as essential and others as implementation detail
- Full backwards-compatibility until next minor release
The background is that
- keeping the code backwards compatible is a huge effort for the core developers, work time (and thus also money) they cannot spend on research and other important stuff.
- It makes more radical design decisions difficult which results in the opposite of agile development. I consider this essential for a research tool to quickly adapt to new situation that have not been foreseen (of course it's always better to do some design decisions right in the first place but that's not always possible).
- We have the problem in DuMux as a research code that basically all classes and functions are in the public interface. Almost every component can be swapped out for a custom implementations (which is one of the strengths of Dumux as a research framework). If you wanted to define the DuMux API it would be just everything we have. However, this means that all classes and functions always have to be altered in a backwards-compatible manner.
Maybe there are some awesome tricks that I don't know, but I find it sometimes extremely hard to find a backwards-compatible solution and find it difficult to find good experience on the topic online. (Maybe noone does it!?)
Of course on the other hand, backwards-compatibility is an extremely useful thing for all users. You can usually update to a new version and get clear instructions how to change your code but your code doesn't break. In an ideal world, we would always want to keep everything backwards-compatible as long as possible.
Opinions & arguments?
I didn't find any good resources online on backwards-compatibility that seems to apply to the situation of research code. Any pointer is greatly appreciated. AFAIK FEniCS relies on a mixture of good changelog and backwards-compatibility where feasible without being mandatory.