知道 swift 不断变化，将第三方 FRP 框架用于长期 运行 项目有多安全？
How safe it is to use third party FRP frameworks for long running project knowing that swift is constantly being changed?
背景：
我需要开始我们希望长期维护的项目（基本上是可重用的组件，将在多个项目中重用）。我正在探索反应式编程，反应式编程给 table 带来的好处是忽略它的方式。
我开始探索可用的各种 FRP 框架，RxSwift、ReactiveCocoa 是少数这样的例子。但看看社区支持和 swift 实施，RxSwift 显然是最佳选择。
现在 RxSwift4 进行了一些重大更改，因为 RxSwift3 与 Swift4 不兼容。现在，社区在顺利地弥合变化方面做得很好，但是 RxSwift3 中实施的 DelegateProxy 之类的东西开始在 RxSwift4 中出现。因此，对于那些使用 RxSwift3 的人来说，这不仅仅是一个 pod 更新，还涉及大量更改。在跟随 RxSwift Git hub issue 之后意识到是因为 Swift4 的变化导致了这个中断。
问题：
现在我们承担使用所有第三方框架的一个非常普遍的风险，但是对于我使用的大多数框架，如果它们出现问题，它们会破坏应用程序中的一两个功能，但如果我在其中编写一个完整的应用程序RxSwift 和未来的更新中断，找到一个可替换的库并替换它将是一项巨大的工作。
这是为什么？
例如，如果您使用 Alamofire，通常您会在应用程序中拥有自己的网络层，这会将某些 API 暴露给应用程序，坦率地说，应用程序不会担心引擎盖下使用的库。所以更换它是一件很容易的事。但是对于 RxSwift，所有异步工具，如 delegates、blocks、notifications 都已经包装在 RxSwift 组件中，如 Observables、Subjects、Units 等我们无法编写自己的包装器，如果当前的 RxSwift 版本在未来的更新中中断，我们将别无选择，只能逐字逐句地修复它们，因为替换库将意味着完全重新编写项目。
我知道这是一种基于意见的问题，但问题是网络上没有太多的指导意见。我真的很感激，如果有人在他们的项目中使用 FRP 框架 post 使用它们的最佳实践，这样对框架的依赖将最小化，并允许我们在未来轻松地转移到新的 FRP 框架。
编辑：
上面提到 Alamofire 只是为了展示包装我们仅在应用程序中使用的其他框架是多么容易，与 RxSwift 本身无关。所以请不要被那个冲昏了头脑:)
我基于简短意见的回答是，从 Swift3 开始就足够安全了，因为从 Swift3 开始就可以保证向后兼容性。我广泛使用 RxSwift 和一系列衍生框架（RxCoreData、RxCloudKit、RxGesture、RxCoreMotion 和 RaspSwift）大约一年了，从来没有遇到过特别麻烦的事情。但话又说回来，你提到了一些我没有使用的框架，它们带来了兼容性问题。所以很明显，可能会有不愉快的意外，开源社区通常会很快解决这些问题。
背景：
我需要开始我们希望长期维护的项目（基本上是可重用的组件，将在多个项目中重用）。我正在探索反应式编程，反应式编程给 table 带来的好处是忽略它的方式。
我开始探索可用的各种 FRP 框架，RxSwift、ReactiveCocoa 是少数这样的例子。但看看社区支持和 swift 实施，RxSwift 显然是最佳选择。
现在 RxSwift4 进行了一些重大更改，因为 RxSwift3 与 Swift4 不兼容。现在，社区在顺利地弥合变化方面做得很好，但是 RxSwift3 中实施的 DelegateProxy 之类的东西开始在 RxSwift4 中出现。因此，对于那些使用 RxSwift3 的人来说，这不仅仅是一个 pod 更新，还涉及大量更改。在跟随 RxSwift Git hub issue 之后意识到是因为 Swift4 的变化导致了这个中断。
问题：
现在我们承担使用所有第三方框架的一个非常普遍的风险，但是对于我使用的大多数框架，如果它们出现问题，它们会破坏应用程序中的一两个功能，但如果我在其中编写一个完整的应用程序RxSwift 和未来的更新中断，找到一个可替换的库并替换它将是一项巨大的工作。
这是为什么？
例如，如果您使用 Alamofire，通常您会在应用程序中拥有自己的网络层，这会将某些 API 暴露给应用程序，坦率地说，应用程序不会担心引擎盖下使用的库。所以更换它是一件很容易的事。但是对于 RxSwift，所有异步工具，如 delegates、blocks、notifications 都已经包装在 RxSwift 组件中，如 Observables、Subjects、Units 等我们无法编写自己的包装器，如果当前的 RxSwift 版本在未来的更新中中断，我们将别无选择，只能逐字逐句地修复它们，因为替换库将意味着完全重新编写项目。
我知道这是一种基于意见的问题，但问题是网络上没有太多的指导意见。我真的很感激，如果有人在他们的项目中使用 FRP 框架 post 使用它们的最佳实践，这样对框架的依赖将最小化，并允许我们在未来轻松地转移到新的 FRP 框架。
编辑：
上面提到 Alamofire 只是为了展示包装我们仅在应用程序中使用的其他框架是多么容易，与 RxSwift 本身无关。所以请不要被那个冲昏了头脑:)
我基于简短意见的回答是，从 Swift3 开始就足够安全了，因为从 Swift3 开始就可以保证向后兼容性。我广泛使用 RxSwift 和一系列衍生框架（RxCoreData、RxCloudKit、RxGesture、RxCoreMotion 和 RaspSwift）大约一年了，从来没有遇到过特别麻烦的事情。但话又说回来，你提到了一些我没有使用的框架，它们带来了兼容性问题。所以很明显，可能会有不愉快的意外，开源社区通常会很快解决这些问题。