本文中的连接多指向目前“内测”阶段的Weex Github仓库 ,如访问时页面出现404提示,欢迎到http://alibaba.github.io/weex/提交内测申请。
Weex于 2016年4月21日在北京QCon大会上宣布开源并同时上线开源站点(http://alibaba.github.io/weex/) 已近一月。对于技术同窗来讲,”开源”一词确定常常听闻,很多同窗仍是知名或低调的开源项目的参与者或建立者。 但此次“Weex开源”第一次让咱们一个技术团队集体参与到开源项目中来, 其中经历,心得和收获我想不管是对于参与其中的同窗,兄弟技术团队乃至业界都是有价值的。 但愿本次和其后的记录能给你们带来帮助。git
“内测”与邀请github
看多了很多“晒代码后撂下无论”式的开源项目 , 也观摩了不少代码质量,开发过程,社区活跃状况皆优的开源项目。同时,Weex又已经在阿里内部开发了近一年时间,并已运用于多个关键阿里产品里。 出于对“开源”和“数据安全”的敬畏, 咱们决定采用如下三步走的策略来推动开源过程。安全
创建Github私有仓库,待经过专利,安全,集团开源委员会审核后把代码push到Github私有仓库,同时迁移开发过程到Github。weex
逐步分批邀请项目组以外的同窗以 “Collaborator”的身份得到Weex Github仓库访问权限,在明确告知现状和规则后,邀请参与Weex开发。框架
彻底开放Github仓库访问权限。工具
咱们目前处于第二阶段 , 对Weex感兴趣的同窗请访问 http://alibaba.github.io/weex/ 提交你的我的邮箱和Github ID, Weex项目组期待与你在Github相会。学习
社区活跃状况大数据
开源首月,截至至2016/05/12, 一共有3414位用户向咱们提交了内测申请, 咱们分11批邀请了其中信息较为完整 (有工做/组织信息,有GithubID ,GithubID有活跃记录) 的1962位用户成为咱们的Github “Collaborator”, 月内,这些最先的Weex外部种子用户一共给咱们提交了130项Github Issue 。某种程度上,这些Issue能够看作业界对Weex的第一印象,项目组同窗们对此很是重视,在每一项Issue下面热情的为提出Issue的同窗答疑解惑, 目前已有92项Issue获得了解决。优化
Github Issue 除了做为“技术支持”的渠道, 同时也是借助社区力量帮助Weex完善的平台。ui
经过这些Issue,有同窗指出咱们文档中的typo ; 有同窗给咱们提了组件完善建议(https://github.com/alibaba/weex/issues/63);有同窗甚至研究了咱们的底层渲染策略后给出了可行的改进建议(https://github.com/alibaba/weex/issues/176); 有同窗经过Issue宣传本身的Weex技术交流QQ群(https://github.com/alibaba/weex/issues/220) ; 固然,也有[这样](https://github.com/alibaba/weex/issues/148)让列表气氛欢乐起来,最后不得不锁帖的Issue。
在自身的改进以外,做为一款UI框架,咱们最期待用户能经过Weex作出新的,超出咱们预计的App或Demo , 首月内,咱们看到了内测参与同窗的回应(https://github.com/alibaba/weex/issues/222) , 虽然略显简单,但Weex项目组同窗很是珍视,由于这令咱们想起了改变世界的Web最初的时候,质朴中蕴含着无限的可能。
月内改进
可视化直观呈现开发过程数据是Github吸引开发者的一大特性, 经过下面的图表能够直观的看出在Weex开源首月,一共有25位同窗在Weex Github仓库进行了401次提交和98次分枝间的Pull Request。
具体的变动记录能够在这里(https://github.com/alibaba/weex/pulse/monthly)查看, 为了保证工程质量,同时让新开发者参与Weex项目更容易,咱们参考了多个开源项目后制定了关于 Commit Log 和 Branch Name的格式规范(https://github.com/alibaba/weex/blob/dev/CONTRIBUTING.md). 每一个内测期受邀的用户,都会在代码库赋权通知邮件中被强调在开始参与Weex前须要学习并遵照这些规范。
本月以内的工做可能是完善,改进和优化。 内置组件中新增了移动应用中常见的Navigation Bar和Tab Bar , List组件也添加了不少同窗期待已久的"pull to refresh"特性。WeexDSL语法也有所加强, 立刻同窗们就能使用起 require/ inline event / require / compute等让你写we时更趁手一些的新语法。
完整的Change Log, 咱们会在随后两天内和Weex 0.5版一块儿在Github(https://github.com/alibaba/weex)上发布。
经验教训
Weex的代码组织结构在开源前发生了一次较大的变化, 在Github提交前,咱们把内部的10多个仓库中的内容合并到一个主仓库中. 这样作的好处是能够方便外部用户更快上手同时汇聚社区关注. 但为项目组也带来了不小的工程负担, 原来能够在不一样仓库中分而治之的Android ,iOS, Javascript团队如今须要在一个仓库中协做. 每一个部分都有独立的构建过程,同时又须要协调一致。
咱们初步的解决思路是让不一样的功能团队在不一样的分枝中进行开发,功能完成后再合并到主分枝。
虽然在同一个库中,Weex不一样部分依赖形式各不相同,有基于代码的依赖,有基于构建产出的依赖。 为了修复问题,某个分枝会产生紧急变动,独立构建版本提供给Weex用户. 面对这样的状况, 咱们最初较为简单的分枝策略经历几回迭代就显现出局限性了,功能分枝合并时都往往遇到各类问题。
为了应对这种状况,咱们把分枝策略进行了升级。 最新的策略(https://github.com/alibaba/weex/releases)以下图所示:
咱们但愿经过多层次的分枝结合CI , 能应付后续更复杂的代码管理情景。
近期规划
Weex目前只开源了Android部分, 咱们知道对于想尝试基于Weex跨终端开发的同窗这是仓促不周的,当前,Weex 开源团队正在全力准备. 预计到6月初iOS渲染器就会和HTML5渲染器,功能更丰富的命令行工具一块儿“准备好行头"来到Github和你们相见。
后续,咱们会根据你们在Github Issue 列表(https://github.com/alibaba/weex/issues)里的讨论,把一些有共性的问题汇总,经过文档或Blog作答。也欢迎你们尝试把本身的Weex使用体验,对Weex的所思所想记录成文投递给咱们, 让这里的文章更加丰富,让其余用户学到新知识, 让Weex开源社区成为一个更好的地方。
阿里百川(baichuan.taobao.com)是阿里巴巴集团的无线开放平台,经过“技术、商业及大数据”的开放,提供移动场景下的高内聚、开放式、行业领先的技术产品矩阵、成熟的商业组件和完善的服务体系,帮助移动开发者快速搭建APP、加速APP商业化进程,全方位赋能移动开发者及移动创业者。