multiple-version（简称：mv）是一个 veronica（1.x） 项目模板，用于搭建大型的企业级项目前端
mv 中的应用层次结构，处于最顶端的容纳整个前端项目的容器叫做产品， 产品包含多个项目或版本。具体到项目内部，一个前端项目包含一个或多个应用（即单页面）， 每个应用包含若干个功能模块，模块包含许多不同的组件
-
root \ 网站根目录
- bower_components\ 包管理工具维护的三方库
- node_modules\ 包管理工具维护的三方库
- www\ 前端产品根目录
-
www\ 产品根目录
- assets\ 自己管理的三方库（多个项目共用）
- product\ 主干版本目录
- xxxx(eg: custom-version-1)\ 定制版本目录
主干版本与定制版本
通常我们需要维护许多个版本的前端代码，一种方式是依赖版本控制工具（例如：Git）来维护， 而在 mv 中，我们不仅通过这种方式，同时从应用程序架构层面就区分了版本，代码严格隔离，这样能够灵活的进行切换和组合，各定制版本只需维护定制的部分代码，能够较好的进行复用
主干版本和定制版本的目录结构完全一致，不同点在于，定制版本只建它定制部分的目录和文件，同时定制的文件需要依赖它所定制的文件，并在原有版本的基础上进行定制或扩展
另一种用法是将版本目录当成项目目录来用，因此 www 下就可以放各个项目，理论上来讲可以把你做的所有项目都放在这个目录里，如果项目间有依赖也可以参照版本目录模式来管理
虽然开发时是把所有项目的代码放到一个大目录来管理，但最终运行的代码是构建过后的，因此上线运行的代码是该代码库的一个子级，这取决于你具体的构建文件配置，你可以使用多个构建文件，这样就能同时维护多个线上版本
下面是某个版本（如：product、custom-version...）内的目录结构
- xxx\
- app\ 该版本内的应用
- modules\ 功能模块目录
- content\ 资源目录，放置公共的样式表和图片及其他资源
- build\ 构建目录，放置运行时和打包构建时的相关配置文件
- assets\ 该版本所管理的第三方库
- app\
- _common\ 多个应用共用的文件
- xxxx \ 单个应用文件夹（eg: home, manager...），每个应用就是一张页面或一个 SPA（单页应用）
- modules\
- xxxx(module)\
- configs\ 放置该模块的配置文件
- meta.js 模块元数据文件（必须）
- backendApi.js 后台接口描述文件
- model.js 数据模型文件
- page.js 路由页面配置文件
- extension.js 扩展配置文件
- ...
- extensions\ 该模块对应用的扩展
- widgets\ 该模块下的界面组件
- configs\ 放置该模块的配置文件
- yyyy(module)\
- xxxx(module)\
widgets 目录
所有的组件都应该使用全局唯一名称，但默认会加上模块名称作为前缀，这里有两种放置方式： 单级目录和多层级目录，单级目录意味着该模块下的所有组件放置同级目录，因此需要取一个长名称以避免冲突， 而采用多层级目录则按照层级来约束，框架在识别是会自动将层级关系拼接成唯一名称，例如可按照如下的分类方式：
- widgets
- 业务类型
- 组件类型
- 组件
- 组件类型
- 业务类型
其中，业务类型是从业务角度进行分类，例如用于总体框架的组件：frame，用于数据管理类型的组件：manage，而组件类型则按照界面功能角度进行分类，并使用通用的语义以便更好的组织 并快速定位，一些通用的类型举例：
- nav：导航类
- list：列表类
- detail： 详情类
- form：表单类
- view：呈现类
构建采用的是 grunt-veronica 插件，每个项目有自己独立的构建文件，构建是该项目模板比较重要的过程，一定要合理编写构建配置文件pack-conf.js，以达到集中式开发，多版本发布的目的，
构建过程如下图所示：
