《Spring Integration for AWS》一直是一個獨立的 Spring Integration 擴充套件專案，擁有自己的計劃和釋出週期。從依賴管理角度來看，使用這個單一的 jar 庫總是增加了複雜性。它不僅依賴於 Spring Integration 模組（如 HTTP 和 File），還直接依賴於Spring Cloud AWS，當然也依賴於 AWS SDK。大多數依賴都是optional的，因為該專案為不同的 AWS 整合（如 S3、SQS、DynamoDB、SNS 和 Kinesis）提供了通道介面卡和元件。因此，目標專案不僅會在 Spring Boot 和 Spring Cloud 版本匹配方面遇到困難，還會受到原生 AWS SDK 庫的影響。

《Spring Cloud Stream Binder for AWS Kinesis》專案也存在同樣的問題。在原生 AWS Kinesis 服務和 KCL/KPL 之間以及匹配 Spring Cloud Stream 版本之間的選擇導致了一些依賴管理方面的麻煩。

這些 Spring 專案從未計劃與主專案合併，成為 Spring Integration 和 Spring Cloud Stream 中的模組，也未成為任何釋出列車的一部分。大多數重用的 API 和自動配置都是從 Spring Cloud AWS 專案中提取的，這導致了釋出週期上的差異，因為後者本身依賴於 Spring Boot 和 Spring Cloud。

我們和你們雙方的這些日常工作，都是因為 Spring Cloud AWS 是一個完全由開源社群管理和支援的獨立專案。即使它在 Spring Portfolio 旗下，由於依賴的複雜性，仍然會將 Spring Integration AWS 和 Kinesis Binder 專案排除在我們的釋出列車之外。

隨著即將到來的 7.0 代版本將於 11 月釋出（Spring Boot 4.0 和 Spring Cloud 2025.1.0），我們決定不再為 Spring Integration AWS 和 Kinesis Binder 專案釋出新的主版本。相反，我們將抓住整個產品組合主版本的機會，提供更合理、更易於管理和更易於使用的東西。Spring Integration AWS 和 Kinesis Binder 專案都將直接合併到Spring Cloud AWS中。

Spring 工程團隊和 Spring Cloud AWS 社群之間的共同努力。目前的工作計劃不是在 Spring Cloud AWS 中提供一個單一的 spring-cloud-aws-integraiton 模組，而是將 Spring Integration 通道介面卡和元件分散到現有的 Spring Cloud AWS 模組中，例如 spring-cloud-aws-dynamodb 或 spring-cloud-aws-s3，併為這個或那個整合 AWS 服務提供帶有所需依賴的專用啟動器，例如 spring-cloud-aws-starter-integration-sqs 和 spring-cloud-aws-starter-integration-sns。請在 Spring Cloud AWS GitHub 問題和拉取請求中加入我們，分享有關此遷移過程的任何反饋。

即將釋出的 Spring Cloud AWS 4.0，基於 Spring Boot 4.0 和 Spring Cloud 2025.1.0，將透過其直接的釋出列車、細粒度的模組化和更簡單的依賴管理模型，為 Spring Integration 和 Kinesis Binder 使用者提供流暢的體驗。合併完成後，Spring Integration AWS 和 Kinesis Binder 專案將在 GitHub 上歸檔，因為它們的開源支援已結束。

此致， 
Artem