河伯
@longyiyiyu 非常的赞，大概扫了一下，很完整的建议，我慢慢消化。
@jiangyuan 开发机目前不能访问imweb.io，公司网络环境决定。暂时先用代理解决吧。也可以考虑同步内部源，我们再统一同步。
@longyiyiyu 办公网的问题，后面再看看是否通过代理来弄。组件规范后续会加强，严格遵循commonjs，其他的已优化。版本号查找正在排期中。
1、duo.js的继承了browserify的思路，在component的基础上去掉了component.json/package.json的一些依赖配置文件，开发的时候不需要另外在关注依赖组件（css也是一样）。但是duo.js只是解决了包的使用，没有解决包的维护和开发。包的维护和开发需要里另外基于github/gitlab来管理和维护，对于前端体系来讲。一个方式是可以基于duo再包装一下解决包的开发/维护（文档） 2、spm是一个完整的体系，但是正是由于他是一些列解决方案，再具体的项目中使用的时候会有一定的工具改造维护成本（诸如spm更新等，当然spm3 已经把构建和包的发布分开，发布不依赖于构建，这一点已经很大的进步），对于未来组件的组织形式，基于这个方案可以这样。基于duo.js的思路，吸收spm的文档组织形式（包管理）我们做一层处理，打包/包的依赖单独处理，再有中间层和本身的spm衔接，至于后续spm方案改了或者换成其他的包管理工具，我们只需要处理中间层。
看了下，semantic versioning的主要思想是语义话的版本号来维护，能够通过版本号找到唯一的版本/api。兼容性也有可以从版本号明确的看出，那么这里我们可以在包管理/加载上做强制升级。
cortex安装CouchDB太TM变态了，还没跑通，明天继续试一下。刚跑了一下spm的整体流程。确实很快。相比较而言，服务部署不是我们的强项，js改造是我们的优势，基于spm改造更适合我们。
 可以提交，这个应该是之前的文档没有更新。http://ctx.io/package/edu-mobile 这个是我之前提交到cortex的测试包。
@webryan 明天我们先内部讨论一下思路和方向，整体的改造方案可以在下周一出来。
@popomore 恩 恩，目前正在修改中，fork一份是考虑修改方便，以免需要的时候不方便改，后续如果有必要会贡献到以前的地方。\* 目前正在修改，稳定之后会改掉这里哈。不用--save的原因是有其他同事在修改的时候，也不用--save来使用，和后续正式发布之后使用方式一致，也免去经常提交修改的package，等稳定版本了，再改回来。
家里终于连上网了。欢迎大家继续讨论建议啊。