undancer

Merge branch 'develop'

1 -# 如何维护更新日志  
2 -  
3 -## 更新日志绝对不应该是git日志的堆砌物  
4 -  
5 -### 更新日志是什么?  
6 -更新日志(Change Log)是一个由人工编辑,以时间为倒叙的列表。  
7 -这个列表记录所有版本的重大变动。  
8 -  
9 -### 为何要提供更新日志?  
10 -为了让用户和开发人员更好知道每一个版本有哪些区别。  
11 -  
12 -### 为何我要在乎呢?  
13 -因为归根结底软件是为人提供的。既然你不关心人,哪么为何写软件呢?  
14 -多少你还是要关心你的受众。  
15 -  
16 -本文档原作者和另外两个人的一个[播客][thechangelog]向大家介绍了,  
17 -为何代码的管理者和开发者应该在乎更新日志。如果你有一小时时间和很好的英文听力本领,  
18 -不放听听。  
19 -  
20 -### 怎么定义好的更新日志  
21 -好问题!  
22 -  
23 -一个好的更新日志,一定满足:  
24 -  
25 -- 给人而不是机器写的。记住,要说人话。  
26 -- 快速跳转到任意段。所以采用markdown格式  
27 -- 一个版本对应一个章节。  
28 -- 最新的版本在上,最老的在下面。  
29 -- 所有日期采用'YYYY-MM-DD'这种规范。(例如北京奥运会的2008年8月8日是2008-08-08)这个是国际通用,任何语言  
30 -都能理解的,并且还被[xkcd](http://xkcd.com/1179/)推荐呢!  
31 -- 标出来是否遵守[语义化版本格式][semver]  
32 -- 每一个软件的版本必须:  
33 -- 标明日期(要用上面说过的规范)  
34 -- 标明分类(采用英文)。规范如下:  
35 - - 'Added' 添加的新功能  
36 - - 'Changed' 功能变更  
37 - - 'Deprecated' 不建议使用,未来会删掉  
38 - - 'Removed' 之前不建议使用的功能,这次真的删掉了  
39 - - 'Fixed' 改的bug  
40 - - 'Security' 改的有关安全相关bug  
41 -  
42 -  
43 -### 怎么尽可能减少耗费的精力?  
44 -永远在文档最上方提供一个'Unreleased' 未发布区域,来记录当前的变化。  
45 -这佯作有两大意义。  
46 -  
47 -- 大家可以看到接下来会有什么变化  
48 -- 在发布时,只要把'Unreleased'改为当前版本号,然后再添加一个新的'Unreleased'就行了  
49 -  
50 -  
51 -### 吐槽环节到了  
52 -请你一定要注意:  
53 -  
54 -- **把git日志扔到更新日志里。**看似有用,然并卵。  
55 -- **不写'deprecations'就删功能。**不带这样坑队友的。  
56 -- **采用各种不靠谱日期格式** 2012年12月12日,也就中国人能看懂了。  
57 -  
58 -如果你还有要吐槽的,欢迎留[issue][issues]或者直接PR  
59 -  
60 -  
61 -### 世界上不是有标准的更新日志格式吗?  
62 -貌似GNU或者GNU NEWS还是提过些规范的,事实是它们太过简陋了。  
63 -开发有那么多中情况,采用那样的规范,确实是不太合适的。  
64 -  
65 -这个项目提供的[规范][CHANGELOG]是作者本人希望能够成为世界规范的。  
66 -作者不认为当前的标准足够好,而且作为一个社区,我们是有能力提供更棒的规范。  
67 -如果你对这个规范有不满的地方,不要忘记还可以[吐槽][issues]呢。  
68 -  
69 -### 更新日志文件名应该叫什么?  
70 -  
71 -我们的案例中给的名字就是最好的规范:`CHANGELOG.md`,注意大小写。  
72 -  
73 -`HISTORY.txt`, `HISTORY.md`, `History.md`, `NEWS.txt`,  
74 -`NEWS.md`, `News.txt`, `RELEASES.txt`, `RELEASE.md`, `releases.md`这么  
75 -多文件名就太不统一了。  
76 -  
77 -只会让大家更难找到。  
78 -  
79 -### 为何不直接记录`git log`?  
80 -  
81 -因为git日志一定是乱糟糟的。哪怕一个最理想的由完美的程序员开发的提交的,哪怕一个  
82 -从不忘记每次提交全部文件,不写错别字,不忘记重构每一个部分——也无法保证git日志完美无瑕。  
83 -况且git日志的核心在于记录代码的演化,而更新日志则是记录最重要的变更。  
84 -  
85 -就像注释之于代码,更新日志之于git日志。前者解释*为什么*,而后者说明*发生了什么*  
86 -  
87 -  
88 -### 更新日志能机器识别吗?  
89 -非常困难,因为有各种不同的文件格式和其他规范。  
90 -  
91 -[Vandamme][vandamme]是一个Ruby程序(由[Gemnasium][gemnasium]团队制作),可以解析  
92 -好多种(但绝对不是全部)开源库的更新日志。  
93 -  
94 -### 到底是CHANGELOG还是更新日志  
95 -  
96 -CHANGELOG是文件名,更新日志是常用说法。CHANGELOG采用大写是有历史根源的。就像很多类似的文件  
97 -[`README`][README][`LICENSE`][LICENSE],还有[`CONTRIBUTING`][CONTRIBUTING]  
98 -  
99 -采用大写可以更加显著,毕竟这是项目很重要的元信息。就像[开源徽章][shields]  
100 -  
101 -### 那些后来撤下的版本怎么办?  
102 -因为各种安全/重大bug原因被撤下的版本被标记'YANKED'。这些版本一般不出现在更新日志里,但作者建议他们出现。  
103 -显示方式应该是:  
104 -  
105 -`## 0.0.5 - 2014-12-13 [YANKED]`  
106 -  
107 -`[YANKED]`采用大写更加显著,因为这个信息很重要。而采用方括号则容易被程序解析。  
108 -  
109 -### 是否可以重写更新日志  
110 -当然。哪怕已经上线了,也可以重新更新更新日志。有许多开源项目更新日志不够新,所以作者就会帮忙更新。  
111 -  
112 -另外,很有可能你忘记记录一个重大功能更新。所以这时候应该去重写更新日志。  
113 -  
114 -### 如何贡献?  
115 -本文档并不是**真理**。这只是原作者的个人建议,并且包括许多收集的例子。  
116 -哪怕[本开源库][gh]提供一个[更新日志案例][CHANGELOG],我刻意没有提供一个  
117 -过于苛刻的规则列表(不像[语义化版本格式][semver])。  
118 -  
119 -这是因为我希望通过社区达到统一观点,我认为中间讨论的过程与结果一样重要。  
120 -  
121 -所以[欢迎贡献][gh]  
122 -  
123 -  
124 -[CHANGELOG]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md  
125 -[CONTRIBUTING]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CONTRIBUTING.md  
126 -[LICENSE]: https://github.com/olivierlacan/keep-a-changelog/blob/master/LICENSE  
127 -[README]: https://github.com/olivierlacan/keep-a-changelog/blob/master/README.md  
128 -[gemnasium]: https://gemnasium.com/  
129 -[gh]: https://github.com/olivierlacan/keep-a-changelog  
130 -[issues]: https://github.com/olivierlacan/keep-a-changelog/issues  
131 -[semver]: http://semver.org/lang/zh-CN/  
132 -[shields]: http://shields.io/  
133 -[thechangelog]: http://5by5.tv/changelog/127  
134 -[vandamme]: https://github.com/tech-angels/vandamme/  
1 # Introduction 1 # Introduction
2 2
3 -Welcome to the boxfish wiki! 3 +Welcome to the boxfish developer docs!
4 - 4 +
5 -# 技术文档 5 +开发文档从github wiki 迁移至 gitbook来完成。
6 -* [服务器接口文档](服务器接口文档.md) 6 +
7 -* [模板类型](模板类型.md) 7 +其中二者是有区别的,比如github中大部分都在自建索引目录,而gitbook要求大家将目录写到SUMMARY.md中,否则将不会将markdown编译成文档。
8 -* [学生版具体模板介绍](具体模板介绍.md) 8 +
9 -* [教师版具体模板介绍](教师版具体模板介绍.md) 9 +## CHANGELOG {#changelog}
10 -* [本地存储相关](本地存储相关.md) 10 +
11 -* [学习统计相关](学习统计相关.md) 11 +开发过程中需要人工书写changelog,为什么要写它?
12 -* [文章元数据](文章元数据.md) 12 +
13 -* [学习结果页面](学习结果页面.md) 13 +请查看 http://keepachangelog.com/zh-CN/0.3.0/
14 -* [逻辑树相关](逻辑树相关.md) 14 +
15 -* [教师版封面学情展现](教师版封面学情展现.md) 15 +## OAuth2.0 {#oauth2.0}
16 -* [活动展现相关逻辑](活动展现相关逻辑.md) 16 +
17 -* [学情统计](学情统计.md) 17 +目前鉴权方式并不属于OAuth,正在调整,预计支持时间为2017年
18 -* [客户端注册登录流程](客户端注册登录流程.md) 18 +
19 -* [教师上传本课讲授词句及评星情况](教师上传本课讲授词句及评星情况.md) 19 +## 状态码 {#status_code}
20 -* [全新模板梳理](全新模板梳理.md) new 20 +
21 -* [适配iPhone6P](适配iPhone6P.md) new 21 +为什么要写这一段,其实我一点儿也不清楚
22 -* [静态资源下载优化逻辑](静态资源下载优化逻辑.md) 22 +
23 -* [动态更新分类优化逻辑](动态更新分类优化逻辑.md) 23 +1. 200
24 -* [在线授课相关文档](在线授课相关文档.md) 24 +2. 401
25 -* [IOS数据客户端相关文档](IOS数据客户端.md)new 25 +3. 500
26 -* [IOS编码规范](IOS编码规范.md)  
27 -* [Android编码规范](Android编码规范.md)  
28 -* [教学效果提升](教学效果提升.md)  
29 -* [外教版](外教版.md)  
30 -* [权限鱼](权限鱼.md)  
31 -* [老师信息接口](老师信息接口.md)  
32 -* [外教点评](外教点评.md)  
33 -* [日志查询](日志查询.md)  
34 -* [静态资源的下载策略](静态资源的下载策略.md)  
35 -* [打电话接口](打电话接口.md)  
36 -  
37 -# 产品文档  
38 -* [学习行为之听力时长统计 20150708update](学习行为之听力时长统计.md)  
39 -* [分享 20150710update](分享.md)  
40 -* [学生版逻辑树 update20150713](学生版逻辑树 update20150713.md)  
41 -* [CRM统计数据 update20150720](CRM统计数据 update20150720.md)  
42 -* [老师版分类上的数据:已学课程](老师版分类上:已学课程.md)  
43 -  
44 -# 测试文档  
45 -* [共通测试](共通测试.md)  
46 -* [学生端测试](学生端测试.md)  
47 -* [老师端测试](老师端测试.md)  
48 -* [微信账号升级](微信账号升级.md)  
49 -  
50 -# 客服文档  
51 -* [客服电话反馈](客服电话反馈.md)  
1 # Summary 1 # Summary
2 2
3 * [Introduction](README.md) 3 * [Introduction](README.md)
4 - 4 + * [CHANGELOG](README.md#changelog)
5 - 5 + * [OAuth2.0](README.md#oauth2.0)
6 -* [CHANGELOG](CHANGELOG.md) 6 + * [状态码](README.md#status_code)
7 -* [OAuth2.0](OAuth2.0.md)  
8 -* [状态码](状态码.md)  
9 7
10 ## 关于用户 8 ## 关于用户
11 9
1 -200  
2 -401  
3 -500