我对这个问题持悲观看法，认为要到年底才能平稳升级，甚至研发失败，以下是我的理解：

1、通常在新版本推出后，升级通道并不会立即打开，在火狐的lts版本、ubuntu的版本等软件升级中，我发现为了确保稳定性，新版本发布后，会延迟，并且灰度打开老版本的升级，这样出现问题时，影响小，准备时间也更充分。4月中下出rc，我估计正式版应该在5-6月，所以即使非常顺利，应该也是7-8月打开升级通道。

2、我在beta3阶段升级20到23，失败了，新老系统都无法进入。 敏捷的做法通常是持续迭代和集成，可以较为透明地看到升级工具和最新版本的兼容性问题，并且将问题拆解到每一个阶段；反观目前deepin，将精力集中在23版本上，“似乎”没有关注升级工具，这样各个阶段引入的兼容性问题，会在最后开发工具的时候集中暴露出来，造成较大的不确定性。 基于此，我在观点1的基础上，将发布工具的可用时间延迟1-2个月， 进而8-10月能打开升级通道

3、工具发布后，用户开始升级，也会遇到各种各样的问题，随着用户反馈，应该正好是年底，可以实现稳定升级。

不要在不使用迁移工具情况下直接改源跨版本升级，那样几乎必然会出问题

你这种情况还是踏实等正式版本出来再升级吧，想平稳升级个人感觉只能是试试，就如一楼所说，一定要备份好数据，做好重装的准备。

我对这个问题持悲观看法，认为要到年底才能平稳升级，甚至研发失败，以下是我的理解：

1、通常在新版本推出后，升级通道并不会立即打开，在火狐的lts版本、ubuntu的版本等软件升级中，我发现为了确保稳定性，新版本发布后，会延迟，并且灰度打开老版本的升级，这样出现问题时，影响小，准备时间也更充分。4月中下出rc，我估计正式版应该在5-6月，所以即使非常顺利，应该也是7-8月打开升级通道。

2、我在beta3阶段升级20到23，失败了，新老系统都无法进入。 敏捷的做法通常是持续迭代和集成，可以较为透明地看到升级工具和最新版本的兼容性问题，并且将问题拆解到每一个阶段；反观目前deepin，将精力集中在23版本上，“似乎”没有关注升级工具，这样各个阶段引入的兼容性问题，会在最后开发工具的时候集中暴露出来，造成较大的不确定性。 基于此，我在观点1的基础上，将发布工具的可用时间延迟1-2个月， 进而8-10月能打开升级通道

3、工具发布后，用户开始升级，也会遇到各种各样的问题，随着用户反馈，应该正好是年底，可以实现稳定升级。