注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Nihui's Blog

nihui的私人空间和日志

 
 
 

日志

 
 

从 tag 到 release  

2008-03-01 14:12:37|  分类: KDE related |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
总是这个惯例,每次 KDE 新版本发布,tag 到 release 有一周的时间。

这一周的时间都在干什么呢?以下我就肆意说说:
KDE 官方是有专门的发布日程表的,上面规定了发布时间,一个 tag,一个 release。
  1. 在新版本发布日程临近的时候,先进行 tag目前 KDE 有几个分支版本:3.5.x、4.0.x、4.1.x。tag 的过程就是在 svn 服务器上面从 trunk/branch 里面复制一份源代码进 tag 目录的过程,tag 的时候,svn 版本号将全部统一成一个最新的。实际进行这次 tag 操作的人员并非是所有具有 svn commit 权限的开发者都可以的,而主要是两位:3.5.x 由 coolo tag,4.0.x/4.1.x 由 dirk tag(coolo 和 dirk 都是 opensuse 的开发人员)。时间也是常例,UTC 23:00 之前的两三分钟(考虑到复制也要时间的,所以没定在 23:00 整)。时间快到之前,tag 操作员先进行版本号升级操作,具体就是修改 kdelibs 里的一个文件里的数字。马上,如果没有重大意外,就用一条简单的命令操作 tag。
  2. 把 tag 目录里的源文件下载下来做成一个源码包(一般也是由 tag 人员操作的)。一旦做好源码包,tag 人员会第一个对其进行编译试验(进行 kdelibs 和 test 程序的编译),编译成功的话,就上传到一个通常的位置(他们叫做“usual place/regular place”),这个地方并非所有人都可以进去下载的,只有各个发行版的 kde 打包人员能进去下载。为了通知大家,tag 人员会在邮件组里发布 tarball 上传的消息。这时候的 tarball 可能会赋予“try #1”的代号。发布团队(release team)还会提醒各个组件的开发者一起写一份 changelog 更新日志。而 release team 自己也会写一份发布公告。
  3. 接下来就是看编译的情况了,基本上应该不太有编译失败的情况,因为早在 tag 之前的几天,各个开发者就会抓紧检查各自的代码,tag 操作的时候也会进行一些 compile patch 的提交。如果有某个发行版平台编译失败(哪怕只有一种发行版),那么在他们内部就会立刻与开发者联系,制作 patch,提交 svn,进行第二次 tag 和制作 tarball try #2。
  4. 一旦基本组件稳定下可以编译,那么 tag 就已经完成了。接下来应该是外围配套软件的 tag,比如 kde4 的 extragear 部分。由于这些软件并没有和 KDE 基本组件的开发周期完全同步,所以需要 tag 的很少。如果需要同时发布,开发人员会通知 release team 代为 tag,比如 KDE 3.5.9 和 KDevelop 3.5.1。
  5. 源码包已经可用了,再下来的几天就是留给打包的了。这的确是比较耗时间的。
  6. 内部使用测试阶段。一旦发现重大的 bug(比方说 konqueror 没法访问 ftp 协议地址),那么会立刻停止发布进程,merge 回上一个版本的样子再发布,或者从 svn 更新里面进行 patch 修复,同时在公告中一起发布。
  7. 正式发布。直接将 kde ftp 主服务器与先前放在内部服务器上的源码包同步即可。

以上只是本人的个人猜想,大致顺序就是这样子了。如果有出入的话,请原谅啦~

  评论这张
 
阅读(305)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017