Erik

那我可以基本认为，最大一个release应该==master。 虽然不太属于这个issue的内容，但我还是想问一句：如果从一个从前的大版本的release出来hotfix，搞定后如何merge到最新的release？ 因为如果允许从历史release去hotfix，并且无法自动merge到最新release，那就会面临下面的选择： 1. 手工merge 2. 不merge 如果不允许，就不会有这些问题

1. 不要从module.conf中找要删除的包，直接从package.json中找 2. 如果package.json中找不到，看看是哪些package.json中声明的dependencies依赖了它，直接做提示，不删除。 3. 如果package.json的dependencies中有它，但是其他dependencies也依赖了它，也不做删除。

我理解，这次的升级，应该是对edp-package一次全面的梳理。所以以前的一些包袱，可以抛弃。 意思就是，可以让使用者重新手工编辑一下package.json里的dependencies

有一个问题，上面的方案认为`module.conf`用于存储项目当前引入包的源信息。但是包改名、多版本并存之类的事情就没法支持了。是不是应该有个新的隐藏文件，用于存储当前引入包的源信息，而`module.conf`经过这个文件生成。 其实，最初设计的时候，`module.conf`仅仅是用于生成require.config的

另外，原先有部分依赖包信息是存在.edpproj文件里的，是继续保留，还是废掉这个逻辑，必须存package.json？ 我个人建议是废掉

另外， @beenlee 从package.json里读dependencies的逻辑是这样的： 先看存不存在edp.dependencies，再看存不存在efe.dependencies，再看存不存在dependencies

先说`dependencies`和`edp.dependencies`。 在通常情况下看来，一个package的依赖，应该写在dependencies里，这很好理解。但是有一种特殊的情况：**这个package是一个浏览器端和browser端都能跑的package，甚至这就是一个node写的业务项目**。 在上面的情况下，node package的依赖与browser的依赖很可能不同。所以我们需要两个： - `dependencies` node 依赖 - `edp.dependencies` browser 依赖 但是，大部分情况下，我们的包是纯粹的（就是个browser package或者node package）。如果我是单纯的browser package，但是我非要写`edp.dependencies`，又会觉得很sb。直接写`dependencies`就好了。 edp-package是管理browser package的。综上，处理逻辑就会变成： - 如果有`edp.dependencies`，就认它 - 如果没有，就认`dependencies` 那么在最后，`efe.dependencies`是个什么鬼货色呢？其实丫啥也不是，现在没有任何地方实现它。因为efe代表的是技术体系，edp代表的是开发平台，所以我个人觉得可能`efe.dependencies`会更好些。但是想了想，没必要搞这么多名字出来。考虑`dependencies`和`edp.dependencies`就好了。如果想要扩展性好点，可以留出配置口。

> 我们是否应该期待所有的配置都在edp下可以被override呢 我觉得可以，再想想除了main好像也没别的了。devDependencies？