FCM和GCM向后和向前兼容吗？
Google正在弃用Google Cloud消息传递，转而采用Firebase Cloud消息传递：
Firebase云消息传递（FCM）是GCM的新版本。它继承了可靠和可扩展的GCM架构体系，加上新功能！查看常见问题解答了解更多信息。如果要在新应用中集成消息，请从FCM开始。强烈建议GCM用户升级到FCM，以便在今天和将来受益于新的FCM功能。
根据我在服务器上进行的一些测试，FCM URL(https://fcm.googleapis.com/fcm/send)用于GCM项目，反之亦然-GCM URL(https://android.googleapis.com/gcm/send)与FCM项目合作。
将所有现有的GCM推送发送代码迁移到FCM将节省很多麻烦和重构（我不必检查每个推送的应用版本是FCM还是GCM）。
这种向后和向前兼容性是否得到官方支持或记录？
共有1个答案
如果您在此处参考@IanBarber的答案：
代币是不同的。Firebase云消息传递（GCM）使用实例ID API获取注册令牌，这意味着您将获得与GCM2不同的令牌。
您需要将新令牌发送回服务器以发送消息。在服务器端，API应该是完全兼容的（只是FCM的新endpoint）。
然而，如果你在寻找任何官方留档，我不认为有一个明确说明它。因为谷歌尽可能鼓励使用相应的API、endpoint等。这取决于你真正打算使用什么。
-
问题内容： 我在一个应用程序中工作，我们需要将对象保存为XML格式，并在以后需要时加载它们。为此，我使用JAXB将XML编组和解编回Java类。 我的问题是我必须在某个时候更改Java模型（通过添加，重命名或删除属性），结果，我将拥有不兼容的保存XML，无法将其绑定回新的类形式。 为了解决这个问题，每次必须进行更改时，我都会在一个新程序包（以其版本命名）下复制所有类的副本，并应用所请求的更改。并且
-
问题内容： 我的理解是，为了维护源代码兼容性，Java从未将新方法引入公共接口，因为这破坏了实现接口的现有客户端。 Java发行说明说明 通常，该政策如下，但以下列出的不兼容之处除外： 维护版本（例如1.4.1、1.4.2）未引入任何新的语言功能或API。他们将保持彼此之间的源兼容性。 功能版本和主要版本（例如1.3.0、1.4.0、5.0）保持向上但不向下的源兼容性。 然而，包和继续发展，并介绍
-
ngrok承诺有关其接口的兼容性和稳定性，以便您可以自信地构建集成顶部，知道在升级到较新版本时期望的更改。 兼容性承诺 Point Release (2.0.0 -> 2.0.1) - ngrok承诺在点发布之间没有突破性的变化 Minor Version Change (2.0 -> 2.1) - ngrok可能会进行小的更改，打破兼容性的次要版本更改。 ngrok承诺，任何破坏性更改将由一个版
-
我正在我的项目中尝试Java8，我被困在与我的构建过程相关的错误中。 我正在使用ANT脚本，在某个时刻，我正在使用一些javascript（嵌入到ANT中）来执行一些特定于构建的操作。导致错误的脚本部分如下所示： 该项目使用Java 7或Java 6构建得很好，但在使用Java 8时，它会给我带来一些错误。这些错误与JS引擎的升级有关。 特别是我得到了以下例外： javax。剧本ScriptExc
-
确保您可以轻松顺利地升级您的应用程序，这对我们是很重要的。这就是为什么我们只在主 要版本里程碑才会打破兼容性。你可能熟悉 语义版本控制 ，这 就是我们在所有的 CakePHP 项目中使用的通用准则。总之，语义版本控制意味着只有主要版 本(比如2.0，3.0，4.0)可以打破向后兼容性。次要版本(比如2.1，3.1，3.2)可能会引入新 的功能，但不能破坏兼容性。错误修复版本(比如2.1.2，3.0
-
我们的系统由多个微服务组成，这些微服务发出并使用以avro格式编码的事件（参见底部的模式）。一个特定的用例如下：服务A在主题T1上发出一个事件（类型为InvoiceEvents），服务B和C（不同的开发团队）在T1上消费。例如，服务B是税务团队的一部分，而服务C是产品履行团队的一部分。 我本以为以下是真的（但似乎不是真的）： 通过添加新的联合类型（即为字段“payload”创建的InvoiceCr