On Sun, Sep 16, 2018 at 12:30:24PM +0000, Daniel Shahaf wrote: > Thanks for elaborating on that, Greg. I agree that the scenario you > describe is something we should design to prevent. > > In a nutshell, I think the point is that we promise ABI forward > compatibility should deliver that even for experimental entry points.
I'm starting to wonder what the point of public experimental APIs really is. They seem to just muddle up our simple public API rules for no good reason. It seems to actual goal here is to encourage third party authors to integrate experimental features in their clients for users to test. Is there more to it? What about just making such APIs private and available under include/private? There is no technical reason why third party clients would be unable to link those functions into their program if they wish to. The private nature makes it very clear that these APIs cannot be relied upon after upgrades. That model is very simple to understand so I would encourage us to not invent anything else if there is no urgent need. So far, I don't see how adding more exceptions and rules to our API guidelines improves anything. Note that our own 'svn' client is already calling private APIs: shelf-cmd.c: SVN_ERR(svn_client__get_diff_summarize_callbacks(&diff_processor, shelf-cmd.c: SVN_ERR(svn_client__get_diff_writer_svn( shelf-cmd.c: SVN_ERR(svn_client__shelf_diff(shelf_version, "", util.c: err = svn_client__assert_homogeneous_target_type(targets);
