Back to Details

checking-breaking-changes-in-php-framework

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Rules for Breaking Changes in PHP Framework

Rules for Breaking Changes in PHP Framework

以下のルールに従って、コードレビュー時に変更が「破壊的変更」か否かを決定する。
Follow the rules below to determine whether a change constitutes a "breaking change" during code review.

@internal
tagがついていないクラス

Classes without the 
@internal
tag

  • 公開API(public method)の引数追加やデフォルト値を設定する以外の変更
  • APIが変わらない場合もAPI内部実装の変更によりAPIのレスポンスが変化する場合
  • 抽象化等により型範囲が広がるが既存と同様のユースケースが可能な場合は破壊的変更扱いしない
  • Changes other than adding arguments to public APIs (public methods) or setting default values
  • Cases where the API response changes due to modifications to the internal implementation of the API, even if the API itself remains unchanged
  • Do not treat it as a breaking change if the type range expands due to abstraction, etc., but existing use cases remain feasible

@internal
tagがついているクラス

Classes with the 
@internal
tag

  • 内部用の実装のため全ての公開APIの変更を破壊的変更扱いしない
  • Since this is an internal implementation, do not treat any changes to public APIs as breaking changes

Code Review Checklist

Code Review Checklist

  • Pull Request が破壊的変更を含むかどうかをレビューに含めます
  • 破壊的変更が行われている場合はその内容が Pull Request の CHANGELOG.md に適切に記載されていることを確認します
  • Include a check in the review to see if the Pull Request contains any breaking changes
  • If breaking changes have been made, verify that the details are properly documented in the Pull Request's CHANGELOG.md