Lapack: 参考-LAPACK/lapack 与参考-LAPACK/lapack-release

我怀疑这只是从 3.7 之前使用的任何 CVS 系统转换并迁移到 github 的结果。 通过删除其中一个并在另一个中追溯标记版本可以获得什么（这可能很乏味甚至在技术上是不可能的，这取决于早期处理源树的方式，并且在任何情况下都会消除拥有的“存档”质量旧版本与创建时完全相同）？

由于一致性，好处将减少混乱。 现在有重叠的数据。

例如，有人正在搜索 lapack 的最新版本，他首先找到了存储库Reference-LAPACK/lapack-release 。 然后他错误地将 3.8.0 用于最新的。 尤其是当存储库被明确称为release时，可能会发生这种情况。
现在还可以在存储库和 netlib 上通过创建问题来提供反馈。

如果为了存档质量而应保留它，则应参考当前的 SCM 进行标记，并且应停用问题以避免混淆。

“lapack-release” repo 中的 README.md 已经指向这里，我确实注意到这个设置在过去几年似乎一直有效，但它可能看起来很不寻常。 （如果可能需要将 3.9.0 分支添加到 lapack-release 存储库中，我怀疑两位维护者都必须将注意力转移到 3.9.0 发布后不久的新冠疫情所创造的新教学条件上）。

他们可能只是忘记将 3.9.0 添加到lapack-release 。 将其作为主干，将另一个作为发布副本，这似乎是 SVN 的习惯。

但几乎从来没有，人们总是使用 GitHub 进行 LAPACK 分发，因为大多数人要么去 NetLib 下载，要么使用其他一些专门的实现。

我确实注意到，这种设置在过去几年似乎一直有效，但它看起来可能很不寻常。

这并不意味着它是完美的设置或不能进行调整。

（如果可能需要将 3.9.0 分支添加到 lapack-release 存储库中，我怀疑两个维护者都必须将注意力转移到...

这可以避免，例如看起来很简单。

他们可能只是忘记将 3.9.0 添加到 lapack-release 中。 将其作为主干，将另一个作为发布副本，这似乎是 SVN 的习惯。

我同意，它看起来像 SVN 分支、主干、标签结构。

你好，我不反对整体架构的重组，按照新的重组架构及时回过头来做事。 几年前我们确实从 SVN 迁移到了 GIT，然后一些更新可能已经溜走了。 如果有人想在这方面带头、标记、重组，并让 LAPACK GitHub 的外观和感觉像最佳 Git 存储库实践的示例，这将是很棒的。 朱利安。

除了我看到“让我们重新安排存储库”成为不止一个“遗留”项目的结尾，我对此没有任何问题，而且我更关心未处理的问题和未获得批准的新功能。

这非常令人困惑，因为 lapack-release 的标语是“LAPACK 官方发布分支”，有没有可能将其更改为“旧 LAPACK 发布分支”之类的东西？

嗨@jfowkes。 “LAPACK 官方发布分支”并没有让我感到困惑。 我们可以添加世界“以前的”发布分支。 我可以添加“以前的”，但我更喜欢保持原样。 欢迎评论。 @langou

嗨@langou ，添加“以前的”会很棒。 当我阅读“官方发布分支”时，我认为所有发布分支都会在那里，当最新的发布分支丢失时，我感到非常困惑。