这些指南描述了当有人下载、检索和解压缩您的发行版时，它应该是什么样子。
新手开发者最常犯的错误是将 tarball 构建为将发行版中的文件和目录解压缩到当前目录中，这可能会覆盖已存在的文件。永远不要这样做！
相反，请确保您的存档文件都具有一个以项目命名的公共目录部分，以便它们将解压缩到当前目录下方的单个顶级目录中。
这是一个 makefile 技巧，假设您的发行版目录名为 `foobar`，并且 SRC 包含您的发行版文件列表，就可以实现这一点。SRC 也可以包含要完整包含的子目录名称。
foobar-$(VERS).tar.gz: @find $(SRC) -type f | sed s:^:foobar-$(VERS)/: >MANIFEST @(cd ..; ln -s foobar foobar-$(VERS)) (cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`) @(cd ..; rm foobar-$(VERS)) |
拥有一个名为README或READ.ME它是您源代码发行版的路线图。按照古老的惯例，这是勇敢的探索者在解压缩源代码后将读取的第一个文件。
README 文件中应该包含的好东西包括
项目的简要描述。
项目网站的链接（如果有的话）
关于开发者的构建环境和潜在的可移植性问题的说明。
描述重要文件和子目录的路线图。
构建/安装说明，或指向包含相同内容的文件的链接（通常是INSTALL).
维护者/贡献者列表，或指向包含相同内容的文件的链接（通常是CREDITS).
最近的项目新闻，或指向包含相同内容的文件的链接（通常是NEWS).
在查看 README 之前，勇敢的探索者将扫描解压缩后的发行版顶级目录中的文件名。这些名称本身可以传达信息。通过遵守某些标准命名惯例，您可以为探索者提供关于接下来要查找内容的有价值的线索。
以下是一些标准的顶级文件名及其含义。并非每个发行版都需要所有这些。
路线图文件，首先要阅读
配置、构建和安装说明
项目贡献者列表。
一个较旧但仍然可接受的约定是将此文件命名为 CREDITS
最近的项目新闻
项目历史
项目许可条款（GNU 约定）
项目许可条款
发行版中的文件列表
项目的纯文本常见问题解答文档
为 Emacs 或 vi 生成的标签文件
请注意，总体约定是，全大写名称的文件名是关于软件包的人类可读的元信息，而不是构建组件（TAGS 是第一个约定的例外，但不是第二个）。
拥有 FAQ 可以为您节省很多麻烦。当经常出现关于项目的问题时，请将其放入 FAQ 中；然后引导用户在发送问题或错误报告之前阅读 FAQ。一个维护良好的 FAQ 可以将项目维护者的支持负担减少一个数量级或更多。
拥有一个带有每次发布的时间戳的 HISTORY 或 NEWS 文件非常有价值。 除此之外，如果您遇到专利侵权诉讼，它可能有助于确定现有技术（这种情况尚未发生在任何人身上，但最好做好准备）。
随着您发布新版本，您的软件会随着时间而变化。其中一些更改将不向后兼容。因此，您应该认真考虑设计您的安装布局，以便您的代码的多个已安装版本可以共存于同一系统上。 这对于库尤其重要——您不能指望您的所有客户端程序都与您的 API 更改同步升级。
Emacs、Python 和 Qt 项目在处理此问题上有一个很好的约定；版本编号的目录。以下是已安装的 Qt 库层次结构的外观（${ver} 是版本号）
/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin # Where you find moc
/usr/lib/qt-${ver}/lib # Where you find .so
/usr/lib/qt-${ver}/include # Where you find header files
|
通过这种组织方式，您可以拥有多个共存的版本。客户端程序必须指定他们想要的库版本，但这与接口不中断相比，只是很小的代价。