> It would help me understand if you would explain how apis were changed in > this PR Sorry, I explained above. it's a small break, maybe it just breaks some unit test mock, but it can be used as an example. > We should be sure to track and then highlight API changes in release > documents. > API changes should be held until the next major version (now 2.12) and be > documented with that release. > I think we need to be explicit in our GitHub PR template. I don’t have a > suggested edit yet, but the idea is to add text about > 1. How the PR changes the API2. Which PIP authorizes it +1 for an awesome idea.
Am I just wondering if we can avoid breaking it? maybe we can give the old method a @Deprecated? Best, Mattison On Dec 7, 2022, 12:56 +0800, Dave Fisher <wave4d...@comcast.net>, wrote: > We should be sure to track and then highlight API changes in release > documents. API changes should be held until the next major version (now 2.12) > and be documented with that release. I think we need to be explicit in our > GitHub PR template. I don’t have a suggested edit yet, but the idea is to add > text about 1. How the PR changes the API 2. Which PIP authorizes it
