我们有一个非常酷的小型 Web 框架，已成功用于数十个客户项目。我们计划将此软件发布到社区。但是，我正在为新的开源软件项目页面上应该/不应该做什么而绞尽脑汁。网站必须具备的东西是什么？文档？一个维基？有下载链接吗？还有什么？
而且，一个相关但可能不同的问题是我们如何开始标记版本号。我们在内部使用的只是 SVN 标记。有没有一种好方法可以确定何时开始调用 0.9 版本与 1.0 和 1.1 等版本？
【问题讨论】：
标签： open-source release release-management
0.9 / 1.0 / 1.1 / 1.0.1 / ... 版本标签仅用于营销目的（在良好的意义上）。这使您的用户/客户可以确定该版本是主要版本、次要版本还是错误修复版本，以及您是否认为它已经成熟。
交付的最低限度是来源。其他可交付成果取决于您愿意如何帮助您的用户并为他们提供支持。
【讨论】：
您可以了解开源项目托管网站所提供的内容：
至于版本号...我认为任何人都没有找到最好的方法：) 考虑到最少，我会考虑：
【讨论】：
查看 GitHub 或 Google 代码。它们为自己的开源项目提供了一个很好的起点。您可以描述您的项目，在 wiki 中记录，使用 git 或 svn 作为您的存储库，并提供下载以及问题跟踪和多开发人员管理。开箱即用的好环境，可供学习和使用。
对于版本号：我不推荐 0.9 或类似的预发布版本。原因？ 1.9版怎么样？它是主要版本 1 的第 9 个子版本还是版本 2 的最后一个预发布版本？我的发布标准在这里描述：http://code.google.com/p/tideland-eas/wiki/ReleaseStandard。我正在使用三数字方案，主要、次要和修复，以及状态代码、alpha、beta、gamma 和发布日期。所以我能够轻松地同时处理多个版本。
希望这会有所帮助。
mue
【讨论】：
首先选择一个网站来托管源代码（例如，SourceForge）。在带有匿名签出的版本控制系统上获取源代码。在那里获取一个电子邮件地址，以便人们与您联系。
将此第一个版本称为 0.1。这是因为您还没有支持该项目的文档。
然后呼吸。
然后开始查看文档，例如 wiki。一旦您了解了所有基本细节，并且您认为该版本已经准备好迎接某个黄金时段，然后转移到 1.0，并开始提供二进制下载。
【讨论】：
请务必考虑来源的许可。
当我查看一个开源项目时，我首先要检查的是许可证。如果许可证不是 GPL2/GPL3/BSD 样式或类似的，那对我来说是一个消极因素。
许可证意味着人们将使用它做什么、它如何发展以及它由发布它的公司拥有多少。通过选择开源，我尽量不依赖公司（他们依赖于他们的股东），我真的选择使用真正免费的软件。
由于开源社区对企业权力非常敏感（Google 目前似乎对此有点免疫），因此您确实必须确保在您的网络上传递真正免费的信息网站和您发布的有关该软件的其他材料。
详细了解 free software 和 open source FSF 的定义。
【讨论】：
关于版本控制，我认为绝对最好的起点是Semantic Versioning。
【讨论】：