On Tue, Jun 13, 2017 at 3:05 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Junio C Hamano wrote: >> On Tue, Jun 13, 2017 at 2:51 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > >>> What is the next step, then? You can find the notion ridiculous but >>> it's how this project has worked in my experience (and how other >>> projects with similar patch-based workflows work). >> >> Does "patch-based" have much to do with this? I agree that distributed >> nature of the development would bring this issue, but I tend to think that >> using merge/pull based workflow would not alleviate it--am I mistaken? > > Thanks, you're right. Distributed is the relevant feature. > > The same issue can even come up when using a centralized version > control system like Subversion or Perforce --- without attention to > API compatibility, someone's change that was thoroughly reviewed and > well tested locally in a developer's working directory can introduce > subtle breakage once they run "svn commit", causing it to merge with > the latest upstream changes. The problem becomes more likely the more > distributed a project is since each developer becomes less aware of > the other changes that their modifications need to be compatible with. > > Jonathan Which would be why early integration (pu) and a good test suite are for. However, it's much easier to catch if you change the name when the function no longer behaves the same. In this case I guess you could argue that the part that changed wasn't part of the API... However, I think I'd lean towards "we had code depending on it, so yes it was". It's ok to add new functionality only obtained by new flags or similar, but not ok to break potentially existing callers. Thanks, Jake