OpenAPITools / OpenAPITools/openapi-diff

Consider removal of deprecated elements as compatible

オープン
#371 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Breaking/Non-Breaking classification
主要言語
Java
スター
1.1k
フォーク
190
PR マージ指標
30日以内にマージされた PR はありません

説明

I'm using openapi-diff quite successfully to avoid accidental changes in the API (and therefore introducing a breaking change). We use it as a part of our pipeline.

The current struggle is: that sometimes one wants to introduce a breaking change (like the removal of obsolete API).
My initial idea would float around a two-step process:

  • marking an element ad deprecated (keeping compatibility)
  • removing the deprecated element

To do that, when processing the list of ChangedOpenApi#getChangedElements I'd need to know if the particular element is deprecatable and decide if the change is incompatible or not.

That looks to me like another SPI but I'm not sure if it's the direction. I know it's currently not possible and I'm not even sure if the direction of my thought even makes sense.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず ChangedOpenApi#getChangedElements と、openapi-diff が現在削除を非互換として分類する方法を調査します。アプローチを決定する前に、既存の拡張ポイントと issue で提案されている SPI のアイデアを確認します。Done では、既存の breaking-change チェックを維持しながら、非推奨要素の削除を互換として扱う明確な方法を提供する必要があります。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
api
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
20/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。