- 小程序版本是编译该小程序时所用的rose库版本。
- app版本是编译该app时所用的rose库版本。
- 考虑到api变换较大，目前要求小程序版本和app版本必须一样。
从下到上，有两个地方需要考虑版本兼容，一是android内核和launcher，二是app和小程序。已有的app是launcher和kdesktop，这里重点说app和小程序。
一、兼容性判断
小程序版本是编译该小程序时所用的rose库版本。
app版本是编译该app时所用的rose库版本。
不论小程序还是app，版本归根都是rose库版本。
app定义了一个变量：min_aplt_rose_ver，指示若想在该版本app运行，小程序至少得有的版本。举个例子，min_aplt_rose_ver是1.0.1-20230919，那要在该版本app运行，小程序版本不能低于1.0.1-20230919。
考虑到api变换较大，目前要求小程序版本和app版本必须一样。也就是说，min_aplt_rose_ver总是等于game_config::rose_version。
二、废弃api
1.1 何时从代码中删除废弃api
目前要求小程序版本和app版本必须一样，那不存在这问题，想废弃删掉就行。等将来api基本稳定，没了这条件，估计会用下面方案。
随着app（rose库）不断更新，迟早会出现一些api会被废弃。那何时废弃，看下面示例。
- 20230919发布版本A。
- 20231119发布版本B。此时认为func-A要废弃了，那在这版本继续提供func-A，但会用上修饰“__attribute__((deprecated))”。
- 20240119发布版本C。删除func-A，此版起不再支持func-A。
总的来说，快要废弃时，会给用上修饰“__attribute__((deprecated))”，并至少给开发者留一个版本的放弃时间。
1.2 lua代码
若要废弃，lua代码只有函数和变量。
1.3 C++代码
相比lua代码，除变量、函数外，C++还多了class。对class，会遇到class要增加成员时的修改后兼容性问题。
举个例子，app定义了个api class：class a，新版本希望向它增加个成员函数func。如果在新版本，直接在class a中增加func并发布，虽然老版本小程序不会使用func，但它用新版class a还是会产生问题。这问题具体是什么，和此个class在内存布局有关，总之，至少个人认为不允许出现这种写法（如果有人能让这种做法变得安全，很想知道）。由于在新版本不能增加class的成员函数和变量，只能用一种变通方法去实现，像用一个参数是class a的全局函数。等到版本迭代，时间上可废弃旧版class a时，再把func作为成员函数加进去，发布新版class a。