我建议我们在没有 #295 的情况下发布 0.2.0。 我们现在在 master 中添加了 API,为了在我们推送 #295 时不破坏 API,我们需要编写一些额外的代码来尽可能地找出连接/离开。
持久的群聊还没有看到太多的测试,如果 0.2.0 是一个破碎的版本,那将是可悲的。 这对我们来说意味着更多的工作,但它使我们能够更快地发布(已经太大且过期)下一个版本,并减轻客户端开发人员立即采用更改的压力。
@sudden6 @robinlinden @zoff99 @JFreegman。
我认为现在发布是个好主意。 我已经打开了一个更新 CHANGELOG.md 的 PR,并且可以在这个周末的任何时候标记一个版本。
@sudden6修复了由 qTox 中的持久组引起的崩溃。 现在可以使用此 PR 对其进行测试: https :
我不支持这个。 从用户的角度来看,持续会议是很长一段时间以来最值得注意的补充,再次无限期推迟会议将是一种耻辱。
我认为我们应该在标记 0.2.0 之前合并 #295。 有几个原因:
qTox 已经在支持会议的路上,请参阅@tox-user 链接的 PR,它不会引起任何重大问题。 我认为其他客户也可以在不久的将来支持它。
@sudden6很难。 我希望看到持久组尽快发布。 但我也终于希望视频修复在客户端。 那个问题已经开放了 2 年以上(即使在 irungentoos 存储库中)。
但你是对的,通常事情会被无限期推迟。
我现在仍然倾向于发布。 并在接下来的几周内跟进 0.2.1(应包括持久组)
@sudden6我终于同意你的看法。 没有这样想,我想你是对的。
@sudden6我已经删除了旧的回调,所以我们现在可以发布 0.2.0,并在不久之后将持久会议放入 0.2.1。
似乎是一个很好的妥协
@robinlinden我已经合并了
最有用的评论
我不支持这个。 从用户的角度来看,持续会议是很长一段时间以来最值得注意的补充,再次无限期推迟会议将是一种耻辱。
我认为我们应该在标记 0.2.0 之前合并 #295。 有几个原因:
qTox 已经在支持会议的路上,请参阅@tox-user 链接的 PR,它不会引起任何重大问题。 我认为其他客户也可以在不久的将来支持它。