背景：
记得我在 HANA Cloud中的版本信息记录以及重要的HDI trace设置 以及：想知道HANA Cloud和HANA的版本是如何发布的吗 分别提到了版本的记录安装历史以及HANA Cloud的相关版本规则。
里边特别提到了内部开发版本，相当于是一个SNAPSHOT版本，如下图：
当时也只是一笔带过，没有过多的描述这个版本。它的正式名称是叫："Early Doption"版本号。
通常用于内部的开发测试。而在正式的生产环境当中，是不会使用它的。
正式的生产环境中采用的是：“Pre-release" 版本。比如下图我们看到的：
这是每个季度发行一次，QRC 2, 这个版本是2022年的第二季度发布的一个版本。而版本号2022.16.27，则是其值。期间可能有一些Patch (补丁），则通过期值来体现。但是(QRC 2/2022)保持不变。
上图则是Pre-release版本的update途径。
而下图则是Early-adoption版本的update途径。
最近碰到一件比较头疼的事情是，我要想将如上图所示的：2023.24.0-4c这种版本升级到2023.28 (QRC 2/2023)，在HANA Cloud的控制台上，居然无法做到。
找到HANA team的相关人员，一问之下，发现它们走的是完全不同的branch和升级路径。
这就有点不可思议了。
他们倒是提供了一种方法：
重新安装（创建）一个数据库实例，以pre-release版本来初始化
将数据migrate并restore到新的实例当中
启动新实例，关闭旧实例
但是这个并不能满足我们这样比较高级一点的要求。我要求数据库实例的全局ID (类似于一个GUID)值仍然是原来的值。于这种方案肯定是不行的了。干脆给他们提了一个这样的需求，只要early-adoption的版本低于pre-release的版本，就应该支持直接的upgrade操作。这种需求应该是很自然的事情。
比如，用户他就用到了Early adoption的版本，体会一些新功能，突然哪天，他直接想切换到生产环境的自式版本，但是并不想做手动的停机migrate操作。这种需求太常见了。
Early-adoption的版本管理，迭代快，是优点，能让用户体会到最新的功能，但同时没有提供应有的升级途径：
直接升级
或者migrate之后，能够还原原来的全局ID
静盼后绪版本有这个功能。
