如何开始一个新的开源项目(4)

　　顶 翻译的不错哦!

　　运营邮件列表的另外一个重要环节是对其进行积极地关注。对于用户或开发者来说，没有什么比自己被忽略更加令人沮丧了。如果你设置了一个邮件列表，花一些时间关注它，并 为那些提问的人作出答复。这是围绕一个项目培育出开发者社区的最佳手段。让一个邮件列表达到像样的活跃度是一件比较费时的事，然而这是值得的。为有意向作出贡献的人提供建议、建议人们在适当的时候提交成果(不要让你的邮件列表变成bug追踪工具!)、并且利用你从邮件列表中获得的反馈来提升文档的质量。

　　Nix

　　翻译于 8天前

　　0人顶

　　顶 翻译的不错哦!

　　使用版本号

　　开放源代码项目的一个常见的错误是忽视使用版本号。版本号对项目的长期稳定和维护时相当重要的。CSS Lint首次发布时没时使用版本号，我很快就意识到错误。当有bug提交时，我不知道人们是否正在使用最新的版本，因为没有办法告诉用户代码是何时发布的，虽然提交的bug已经修复但用户无从知晓。

　　Nix

　　翻译于 8天前

　　0人顶

　　顶 翻译的不错哦!

　　将每个发布的版本用官方的版本号来标记，当有人提交bug时，你可以询问他们使用的版本并检查bug是否已经修补。这大大缩短了我花在报告bug 上的时间因为我可以马上知道用户是否在使用最新版本。

　　Nix

　　翻译于 8天前

　　0人顶

　　顶 翻译的不错哦!

　　除非你的项目以前有过使用并已经通过审核， 否则以0.1.0位启动版本号并递增每个后续发布的版本。在 With CSS Lint中我们增加了第二个数字在作为计划版本号，因此，0.2.0便是第二个计划版本号，0.3.0是第三个以此类推。如果我们为了修补bug而需要发布一个介于两个计划版本之间的版本，我们需要增加第三个数字。因此在第二个计划版本0.2.0之后的非计划释出本版号就为0.2.2.

　　不要误解。这里并没有什么规则来规定在一个项目中如何增加版本号，尽管这里有些值得参考的东西 Apache APR Versioning and Semantic Versioning. 我只是挑出来一些并遵循罢了。

　　除了对项目跟踪的帮助，版本号当然还可以为你的项目做一些其他的事情。

　　TX

　　翻译于 7天前

　　0人顶

　　顶 翻译的不错哦!

　　源码控制中的标记版本

　　当你决定要发布一个新版本时，应用源码控制标记来标注此版本的代码状态。当我们开始在CSS Lint中使用版本号，我也就开始这么做了。开始我没考虑那么多，直到有一次我忘了给一个发布版添加标记，但是发现某位开发者提交的bug却是针对那个特定标记的。这说明开发者们更倾向于检出特定版本的代码。

　　TX

　　翻译于 7天前

　　0人顶

　　顶 翻译的不错哦!

　　要让标记和版本号的绑定关系更明确，就把版本号直接包含在标记名称中。在CSS Lint中，我们的标记都使用“v0.9.9”这种格式。这样可以让每个人都能够很容易地通过标记名称来识别其含义 — 包括你自己，因为你也将能够更好地跟踪每次版本发布的改动。

　　TX

　　翻译于 7天前

　　0人顶

　　顶 翻译的不错哦!

　　变更日志

　　版本管理还有一个好处就是能够生成变更日志。不管是对最终用户和贡献者，变更日志都是沟通版本差异时的重要依据。版本标记和源码控制有一个附加好处，你能基于这些标记自动生成变更日志。CSS Lint的构建系统能够在每次发布是自动生成一个包含提交信息及其贡献者的变更日志。这样变更日志就不仅只是一个代码变更记录，也是社区贡献值的记录。

　　TX

　　翻译于 7天前

　　0人顶

　　顶 翻译的不错哦!

　　可用宣告

　　每当项目发布一个新版本时，都应该在某处发布宣告。不论是在你的博客或邮件列表或是在两者上都发布，正式宣告项目新版本已经可用是非常重要的。这份宣告应该包括项目代码的主要改动及其贡献者。对贡献者工作的认同是对他们的最大鼓励，能从贡献代码中获得更多的认同感他们就更有动力做更多的贡献。所以给予那些耗费无数精力在你的项目中的开发者以最大的赞扬吧。

　　TX

　　翻译于 8天前

　　0人顶

　　顶 翻译的不错哦!

　　管理代码贡献

　　万事俱备，下一步就是解决如何接受代码贡献。 你的贡献模型是非常规范还是很随意，取决于你的喜好和目标。对应个人项目，可能不需要什么规范的贡献流程。开发者指南应该说明合并代码到仓库的必要条件，一个提交先要满足这些条件才会被接受。对于更大的项目，应该要有更多规范的策略。