Autofixture: 讨论：“Ploeh”命名空间前缀

据我所知，绝大多数 OSS 项目的根命名空间与名称相同，所以我在这里看不到任何问题。 由于这将是一个重大更改，因此您只需要增加主要版本。

👍 在破坏版本中将根命名空间更改为AutoFixture 。

我不介意保留 Ploeh 命名空间。 所有权不相关和
名称空间在完美运行的事情上发生了变化，为什么..？

在Sun，2017年4月2日在14:04亚当拉尔夫[email protected]写道：

👍 在破坏版本中将根命名空间更改为 AutoFixture。

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

我同意整体分析（上面概述的利弊）。

正如这里的几个人已经指出的那样，更改命名空间将是一个重大更改。 OTOH，由于治理的变化，在版本 3 和版本 4 之间更改命名空间似乎至少是可以防御的。 在第 4 版和第 5 版之间删除“Ploeh”要困难得多。

如果你想从命名空间中删除“Ploeh”，现在是时候去做了。

@ploeh感谢您的回复。 再问你一个问题——你个人更喜欢哪个选项？ :) 我知道这是一个有点棘手的问题，但我相信我不是唯一一个对它很重要的人，因为您是创始人（或联合创始人，我不确定：flushed:）。

我更喜欢你做出你认为最有利于项目前进的决定 😉

从外部的角度来看，我可以看出拥有命名空间Ploeh.Autofixture使我第一次使用该库变得稍微困难​​一些，因为命名空间与包名称或 GitHub 上的项目无关。

键入using Auto...并从 Intellisense 收到一个空列表，这有点令人惊讶。

我同意@Kralizek。
但是将项目重命名为 Fixture.Net 的问题（尽管我个人支持这一步）将意味着打破 .NET 社区名称中相当广泛和众所周知的名称。

同意@ploeh写的

如果你想从命名空间中删除“Ploeh”，现在是时候去做了。

当然，这可能只发生在v4分支中。

命名空间更改相当简单，搜索和替换，您可以在自己的源代码中完成。

如果其他软件包正在使用 AutoFixture 并且在 nuspec 中没有正确的版本分隔符，则问题出在 nuget 上，那么这也会中断。 但是暂时用户可以轻松返回到 AutoFixture 3.x。 这可以在文档、发布博客文章或其他内容中解决。

我赞成从命名空间中删除 Ploeh，我从不喜欢命名空间中的个人姓名，在我的项目早期这样做，讨厌我这样做;)

如果其他软件包正在使用 AutoFixture 并且在 nuspec 中没有正确的版本分隔符，那么这也会中断

我不会担心的。 每个破坏版本都存在同样的问题。 如果下游软件包选择不对下一个主要版本设置唯一的上限，例如<dependency id="AutoFixture" version="[3.0,4.0)" /> ，那么每次发布 AutoFixture 的主要版本时，它们都会引发这个问题。

@abatishchev Fixture.Net来自另一个讨论吗？ 我会很高兴只需将命名空间更改为AutoFixture

@moodmosaic您能否补充一下您对此的立场？ 我相信我们需要听取所有核心维护者的意见才能做出最终决定。

我已经做了。

@moodmosaic我看到了那个答案，但我不确定我得到了你的位置。 你投票是保留命名空间还是删除它？ :)

我投票赞成保留它。 破坏性较小。

为什么做破坏性的事情会让你担心？ 很多人要求这种改变。
更不破坏性的将项目保持原样，根本不做任何更改。 但这不是这个过程的全部内容，不是吗？
我个人希望看到您继续进行此更改。

@moodmosaic我看到了那个答案，但我不确定我得到了你的位置。

如果根命名空间在v4重命名为AutoFixture ，我会很好。

虽然我支持我之前对保留Ploeh命名空间的投票，但如果这是大多数人想要的，我可以将其删除。

考虑到所有权的变化，我明白这对项目的推进意义重大，而且时机恰到好处。 在这一点上，我能提出的唯一反驳完全基于情绪。

@ecampidoglio ，我也有情绪，但我认为在 v4 中仅使用 _AutoFixture_ 更“正确”......

@moodmosaic感谢您的回复，同样的事情也发生在我身上。 我对这个项目了解得越多，我看到和意识到 Mark 在这里所做的工作就越多——大量不同的讨论、细微的调整、对 SO 的回复等。做出修剪前缀的决定变得越来越难——它看起来对马克不屑一顾。

从另一方面来看，我确实理解简单的AutoFixture前缀看起来会更好和一致。 事实上，这里没有什么可怕的，因为 Mark 的名字仍然会出现在包作者、维基、问题的列表中。 @adamchester和@ecampidoglio投票保留前缀变得更加难以做出决定 - 很多情感的东西在这里存在。 很可能，我们应该将情感方面分开，不要把事情混在一起。 就我个人而言，我不会将名称空间修剪视为 Mark 的工作折旧行为 - 对我而言，原因是纯粹的家务劳动。 即使没有前缀，我仍然会非常感谢他。

但是由于我开始做项目太晚（没有人认识我），我觉得我不能完全理解Mark的贡献，因此，最终决定权绝对取决于核心贡献者。

@zvirja我想你误解了我之前的评论：

如果这是大多数人想要的，我可以将其删除。

所以，是的，我宁愿保留它，但我对 v4 中的AutoFixture命名空间没问题。 😉

我的观点与@ecampidoglio基本相同——我宁愿保持命名空间原样，只是为了避免对用户造成不必要的干扰，但我可以在 v4 中将其更改为AutoFixture 。

对马克来说，它看起来很不感恩。

别担心。 你能给我的最好的感谢就是让 AutoFixture 保持活力。 如果你能做到这一点，我就成功地创造了一些本身就可行的东西。 没有什么比这更令人满意的了。

谢谢你的回复，马克！

鉴于上述所有答复，并且核心团队不介意更改命名空间，我会将其添加到 v4 范围中。

我忽略的另一件事是 - 程序集名称。 目前的程序集名称似乎也以 Ploeh 开头。 如果我们删除命名空间前缀，那么重命名程序集也是有意义的（例如从Phoeh.AutoFixture.dll到AutoFixture.dll ）。 我相信 NuGet 会优雅地处理这个变化。 我们唯一可以担心的是，这将是一个新的程序集标识，并且无法执行从 v3 到 v4 的程序集重定向。

您如何看待这个@moodmosaic 、 @adamchester和@ecampidoglio - 您对程序集重命名有异议吗？ 这看起来是一个重要的变化，但还没有准备好评估多少。

一旦命名空间在 v4 中重命名，程序集绑定重定向到 v4将毫无意义。 出于这个原因，为了保持一致，我认为将程序集重命名为 AutoFixture(.*) 是有意义的。

好点，我错过了。 实际上，所有类型的全名都会不同，因此重定向没有意义。 除非@adamchester和@ecampidoglio有其他问题 - 让我们也更改名称。

完毕！ “Ploeh”命名空间和程序集名称前缀将从 v4 中删除，因此它将以“AutoFixture”开头。 此更改允许反映更新的所有权，因为现在产品仅由 AutoFixture 团队开发。

请记住，就装配而言，这打破了连续性线。 即，新包将不包含新版本的程序集。 相反，先前的程序集将被删除，并由具有新标识的全新程序集取代。 这意味着绑定重定向之类的东西不能在包 3.x 中包含的程序集和 4.x 中包含的程序集之间工作。

也许这不是问题，但我认为值得指出。

顺便说一句 - 您是否检查过升级包时 NuGet 的行为？ 对于 SDK 风格的项目，我想一切都会好起来的，因为该项目只包含一个<PackageReference>元素指向包而不是程序集。 但是对于旧样式的 csproj，可能值得验证 NuGet 对程序集引用进行了所需的更改，从一个程序集到另一个程序集。

@adamralph感谢您的关注！

这意味着绑定重定向之类的东西不能在包 3.x 中包含的程序集和 4.x 中包含的程序集之间工作。

是的，我知道。 但是，我们已经更改了默认命名空间，这意味着我们更改了程序集中所有类型的标识。 在这种轻量级的程序集绑定重定向中没有任何意义，因为在没有重新编译和导入修复的情况下，代码在任何情况下都无法工作。 因此，我相信我们对此完全没问题。 这是一个巨大的变化，但它只会发生一次。

顺便说一句 - 您是否检查过升级包时 NuGet 的行为？

是的，我已经测试过了，它工作正常。 您唯一需要做的就是运行文本替换以将using Ploeh.AutoFixture修复为using AutoFixture 。 在该项目成功编译并成功运行测试之后。

您唯一需要做的就是运行文本替换以将 using Ploeh.AutoFixture 修复为 using AutoFixture。 在该项目成功编译并测试运行成功后。

对，就是这样。