绑定分割计划、仓库结构变更通知以及对贡献者的呼吁

大家好! 正如您可能已经注意到的那样,我越来越没有时间维护庞大的 Unicorn 仓库了,因为我必须熟悉 Unicorn 项目的每个细节,包括不同的绑定及其分发。这耗费了大量的设计、测试、CI 和分发时间,并阻碍了潜在的贡献者。现在我认为这是一个很好的机会,可以将绑定从我们的单一仓库中分离出来,这样我就可以专注于 unicorn 核心语义,因此我呼吁贡献者。 一般来说,绑定分离的过程如下: - 我将在 `unicorn-engine` 下创建不同绑定的单独仓库。 - 如果您有兴趣参与贡献,可以在这里留言或私下联系我,如果您害羞的话。我的联系方式很容易找到。 - 刚开始的时候,我将帮助设置大部分内容,解释我们的惯例。 - 您将被授予一个基本角色,可以参与审查 PR。在这一时期,所有 PR 需要成员的同意才能通过。 - 一旦我们认为您已经成熟,我们将授予您无需我们同意的权限来合并 PR。 为什么这对社区有利? - 绑定版本可以独立存在,不再与我们的主仓库绑定。这使绑定的发布和迭代更加快速。 - 对于贡献者的门槛可以降低,从而吸引更多人参与。 - 贡献将变得更容易,因为新手不再需要处理整个大项目。 - 这使我们的 CI 工作流程更简单,避免了绑定失败阻碍我们的主要发布。 潜在的副作用是什么? - 一些应用可能依赖于绑定版本与库版本相等的假设。这将破坏这一假设。 - 一些下游包装需要指向我们的新仓库,因此需要手动升级它们的脚本。 - 我可能会遗漏的其他事情。 优先级列表和需要帮助的事项 - Java: 我们需要将其发布到 maven 中。 - Golang: 需要优化和更好的构建过程。 - Rust: 需要使用 `unicorn` crate。 - 其他小型绑定,如 zig ruby 等。