I am not in favor of PRs for every commit. It would really slow down response time for Serkan's and Pashmina's issues.
For the example you cited, I would just search my inbox for "BrowserResizeHandler" and the commit showed up. What would be interesting is some way to detect API changes. Writing more unit tests would help for sure, but this thread got me wondering if the compiler could generate tests based on APIs used, similar to the API report. The cheapest solution, IMO, is just to get everyone to agree not to change APIs in Basic without prior discussion. Probably major code-path changes too. My 2 cents, -Alex On 6/18/20, 2:36 PM, "Harbs" <[email protected]> wrote: One recent example: Carlos recently changed BrowserResizeHandler because he implemented a newer version which is not application-specific. A good idea and one I support. However, it does break existing applications which use BrowserResizeHandler due to a rename. I happened to notice his commit, so when my app got an error because BrowserResizeHandler was not recognized, I knew right away how to fix it. I could have just as easily missed his commit and been clueless why my app suddenly broke. If there was a PR, it also would have given a good opportunity to raise an issue with the change if I would have had one. If a change does need to be reverted, PRs also make reverting very painless. > On Jun 19, 2020, at 12:28 AM, Harbs <[email protected]> wrote: > > Not breaking things per se. More like being able to see at a glance what has been done without wading through commit messages. > >> On Jun 19, 2020, at 12:23 AM, Christofer Dutz <[email protected] <mailto:[email protected]>> wrote: >> >> If you are having trouble with people breaking things and want to solve this problem that way, so you have the additional bandwidth to do the reviews? >> >
