背景：
记得我在 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
静盼后绪版本有这个功能。
原文作者：数据库杂记；如有侵权，请联系管理员删除。
最新文章
- PostgreSQL Internals之路 Part-II 第10章 WAL日志
- 从Oracle过渡到PostgreSQL: 理解模式的概念
- PostgreSQL是Oracle的一个可行的替代方案——原因如下
- PostgreSQL Internals之路Part II: Buffer Cache和WAL第9章 Buffer Cache
- 天纵奇才 - "林诗栋"
- 没有PostgreSQL样例数据库,不用担心, 帮你搞定！
- 推荐几本数据库技术图书
- 由浅入深高可用：HAProxy + PostgreSQL配置逐步详解(二)
- PostgreSQL Internals之路 Part-I 第7,8章 冻结、重建表和索引
- 乒坛最新消息引发巨震 - 世界第一王楚钦惨败林诗栋，王曼昱0-4遭横扫，还有孙颖莎4-2稳胜张本美和
