版本与迭代、发布的关系

关于“版本”的设计讨论：

版本，有集成版本和非集成版本。非集成版本，必须关联迭代处理，为什么设计成这样？

版本为什么不能只关联产品分支（产品型项目），或只关联项目（项目型项目）？

目前的设计，如果迭代周期短，则不能提前设置版本，难以使用版本来提前做“版本计划”和“测试计划”。

要建好迭代，才能做版本计划。

并且，间接地限制了迭代必须足够大，否则可能多个迭代才能完成一个版本，此时操作极其麻烦，反复切换版本与迭代的关联，同时还要处理关联的需求、缺陷等等。（大的迭代，可能导致工时估算、燃尽图，等功能的存在意义和作用都降低）

问题1：

在项目视图创建发布时，不关联版本，默认会关联主干（项目关联的是其他分支），

修改这个“发布”时，无法再关联其它分支，也无法修改关联其它分支的需求或版本。

问题2：

集成版本，创建时不能选分支，默认为主干。

建一个非集成版本，在项目视图不能修改该版本为集成版本；

但在迭代视图，可以把版本的关联迭代去掉，保存后自动变为集成版本，并且此时该版本的关联分支是之前分支，而不是默认为主干。

（建议去掉版本与迭代的关联，或把版本的所属迭代，改为非必填项）

你好

禅道中非集成版本是指项目下某个迭代中完成的需求和解决bug进行测试时打包的版本。

其实都是在某个迭代下进行管理的，可以从某个迭代-版本进行创建，也可以在项目-版本创建时选择到某个迭代上。

集成版本是指项目下对某几个迭代完成的需求和解决的bug进行集成测试时打包的版本。所以集成版本这里可以不选择具体迭代。

如果咱们不是在每个迭代完成部分功能后就打包版本进行测试，而是多个迭代完成后集中打包测试的话，可以在项目下创建集成版本，然后关联相应的需求和bug。

咱们这里的“版本计划”和“测试计划”是否是指发布的计划？如果是的，可以在产品-计划中对产品的版本发布进行创建计划。如果计划按期完成，可以在产品下创建对应的发布。项目、迭代中的版本，更多的是对已完成的需求和解决的bug限定一个测试范围创建版本后，对版本进行提交测试。

另外，如果咱们的一个项目就是一个迭代的话，也可以在创建项目时勾选不启用迭代概念，这样进入项目后可以直接在项目下创建任务、版本等信息，不需要再单独创建迭代。

产品或项目发布时，通常建议是对某个版本进行发布的。项目创建发布时不关联版本，会默认关联到产品主干上的问题，我们记录下反馈。

目前发布后是无法再编辑修改关联的产品分支的。