API軟件包的語義版本控制

Question

在API軟件包中以1.0.0版本開始的軟件包中，在將新界面添加到該軟件包後，新版本應該如何？ whitepaper聲明瞭兼容性：

很明顯，二進制兼容性在向後兼容性中起着重要作用。但是，向後兼容性也非常依賴於語義。如果界面的責任發生變化，它仍然可以是二進制兼容的，但不再向後兼容。

同時...

3.micro - 在微觀部分的差異不表示有任何向後兼容問題

一個新的界面不會導致任何二進制它的提供者不兼容—它可能簡單地省略一個實現。這被認爲是包裹語義上的「後向不相容」變化嗎？這是否意味着新版本應該是1.1.0？

Answer 1

添加一個接口到一個包至少是一個小的改變（1.2.3 - > 1.3.0），因爲你打破了API的提供者（在OSGi是一個包），API的提供者幾乎沒有向後兼容性，因爲它們提供了API。畢竟，API中的任何新義務都需要一些新的代碼。

現在假設您在消費者身上放置了一個義務以在API中實現此新接口。這種變化（編譯器不可見）明顯地打破了所有現有的消費者，並因此成爲每個人的突破性變化（例如1.2.3 - > 2.0.0）。

總之：

• 微小變化 - >與API
• 輕微改變現有的提供者和消費者向後兼容 - >現有的API提供者是不兼容的，但消費者是
• 重大變化 - >現有的提供者和消費者不再兼容

Answer 2

的semantic versioning確實提到：

主要版本X（X.y.z | X > 0）如果有不兼容向後變更向公衆介紹了API必須遞增。

如果除了調用幾個舊接口（現在鏈接成一個新操作），新接口的添加應考慮語義向後兼容。
在這種情況下，次版本增量就足夠了。