我現在正在爲API開發我們產品的功能。開發API：在新功能和後向兼容性之間達成平衡
第一個版本發佈了，目前用戶數量很少。自從我開始開發第二個版本以來，一些零件被重新加工，一些零件被刪除以使API更加優雅和清晰。
但是第二個版本的部署對於老版本的用戶來說可能會很痛苦。 我們的營銷部門正在計劃增強我們的API產品，增加更多功能。
我應該如何建立系統，所以
1）我們不會受限於「舊版本」，以添加新的有趣的功能
2）當前API用戶不會不滿意，因爲是否需要對其系統進行返工以符合更改後的API，或者應該在公開發布前在相當長一段時間內在沙箱中對API產品進行測試，因此不會有任何重大修改在規範中？
當您必須對已經有一些用戶的API進行更改時，最好的方法是棄用舊的API調用並鼓勵使用新的調用。
刪除舊API調用的功能可能會破壞舊代碼的功能，因此可能會導致一些使用「舊」API的開發人員變得有些不滿意。
如果您的語言提供了某些功能已被棄用的方式，則可以指示用戶停止使用舊的API調用並轉換到新的調用。在Java中，@deprecated javadoc tag可以在文檔中提供某個功能已被棄用的註釋，或者從Java 5開始，@Deprecated annotation可用於在調用已棄用的API功能時引發編譯時警告。
另外，提供一些關於從舊API遷移到新API的技巧和提示可能是一個好主意，鼓勵人們使用與API交互的新方式。通過示例和示例代碼來說明如何做以及不該做什麼，API的用戶將能夠根據新的首選方式編寫代碼。
改變一個公共API很困難，但是在從舊到新的過渡時需要注意，我相信API的用戶造成的疼痛量可以減輕到一定程度程度。
這是關於來自Sun的How and When to Deprecate APIs的文章，它可能會提供一些關於什麼時候適用於棄用部分API的更多信息。
此外，感謝David Schmitt補充說.NET中的Obsolete attribute類似於Java中的@Deprecated註釋。 （不幸的是，編輯是由我編輯改寫，因爲我們都在同一時間編輯這個答案。）
這是一個平衡，你將與你的社區罷工：
保留舊功能而且你最終會得到Win32 API（30000 public 函數）？
一直重寫API，你可以得到類似於.NET的東西，在那裏每隔一段時間（1.0,2.0,3.0,3.5 ...）發佈一個新的修訂版，並打破現有的程序或引入新的和改進的用戶界面做等方式）
如果社會是寬容的變化和開放的嘗試，你會爭取一個精幹，當前API和知道有些破損，又名位腐爛，會導致。另一方面，如果社區擁有大量的遺留代碼並且沒有資源或希望將其提升到最新版本，則必須保持向後兼容性，否則它們的所有內容都無法在新API上使用。
注到其他的答案之一：自嘲的API是指示一種常用的方式，其功能是「在路上了」，但只要他們的工作，許多開發商將在偶數中使用它們新代碼，因爲這些是他們習慣的功能。很少有開明的開發人員能夠意識到實際上已經注意到「棄用」警告，並且有時間爲代碼查找舊API的其他實例並對其進行更新。
微軟因其瘋狂的向後兼容性而出名。他們所做的一件事就是保留所有舊的過時調用，然後添加新程序，新程序可以使用這些新程序訪問舊API無法工作的增強功能。
您沒有指定使用哪種編程語言，但.NET和Java都有將某些API調用標記爲過時的機制。如果向後兼容對你來說非常重要，那麼你可能需要採取相同的路線。
向後兼容性應該是默認值。你應該妥協這個原則的唯一原因是API在某種程度上是不安全的，這迫使用戶改變爲更安全的方法。
寫入原始API的Idealy應用程序將繼續與新版本一起使用。
在確保舊應用程序繼續運行的同時添加新功能的一種方法是使用兩個API調用版本。
例如，假設您目前有一個函數Foo，它會在API中使用2個參數（參數），但是您確定新版本確實需要3個參數。保持美孚它的方式，並添加一個新的功能Foo2它需要3個參數。
這樣，用戶就可以繼續對碼符爲向後兼容或使用新的foo2的功能，如果他們需要的新功能。
這種技術已被微軟廣泛用於Windows API。