如何分别对待debug 和release 版本
raymond
那么，在某个阶段我们需要发布realease版本的时候，realease和debug版本的关系是什么呢？
比如我们采用这种方式：
两个branch，一个是realease版本，一个是debug版本，那么就会出现这样的情况
release版本：可以给最终用户用的
debug版本，正在开发的，还在添加新功能的。
1. realease版本上发现了一个bug之后，我们fix掉bug，然后再仔细检查debug版本上当前是否还有这个bug（为什么仔细检查
呢？因为在realease版本被使用的过程中，debug版本已经进行了很多的改变，其code base和realsease都不一样了，同样的
bug fix的方式都可能不同）
2. 反之亦然，如果debug版本发现了一个bug，那么也要考虑realease版本是否需要修复？如何修复？
我觉得以上方法使得同一个功能的开发者对同一个bug可能要做两份类似的工作，而且会带来潜在的风险，那就是某个阶段realease和debug版本
已经完全没有关系了，这显然是不合理的。
那么，大家能否介绍一下在实际的大型项目中如何管理debug和realsase版本呢？如何能够使得dev尽可能少的做重复的工作？如何避免
merge代码时候的误操作（比如realease的buf fix 被merge到了debug上，结果。。。。。）。
让我们猜猜，windows这么庞大的软件，每年都有realease出来，那么其内部如何管理【realsease版本】和【当前正在开发新功能的
debug版本】呢？
翁翊成
关于debug branch，我最近在学习git的过程中，感觉git十分提倡基于branch修改代码，稳定后再合并到master并push出去。所以，我认为应该存在很多的branch，每个新的需求、bug、变更都应该有相应的branch对应，这样也好到缺陷管理系统如trac中与签票做对应。
综上所述，每次的发布都应该是认真严肃的，发布出去的东西就尽量不要再想办法去修改他，那会带来更大的问题，所以每次发布前做tag，tag的东西是没有必要再去改的，要改就到下一版本再说；而针对当前持续开发的过程，尽量多开分支，每次修改代码建立一个分支，代码向主干的提交的过程中一定要做好code review，保障程序尽量少的出问题，这就是一个策略问题了。所以，我的观点是：没有release分支，而是一大堆针对不同时期release版本的tag；也没有debug分支，很多的分支，针对不同的情况建立不同的branch修改代码，控制好代码提交、合并的流程。
redsea
working branch 可以合并这些修改.
On Dec 8, 12:10 am, 翁翊成 <weng...@gmail.com> wrote:
> 感觉针对release采用tag的方式管理更妥善些。产生了bug之后没必要立刻在release里修改，而要考虑配合另外的缺陷、问题管理追踪工具搭配SCM来管理bug。
> 关于debug
> branch，我最近在学习git的过程中，感觉git十分提倡基于branch修改代码，稳定后再合并到master并push出去。所以，我认为应该存在很多的branch，每个新的需求、bug、变更都应该有相应的branch对应，这样也好到缺陷管理系统如trac中与签票做对应。
>
> 综上所述，每次的发布都应该是认真严肃的，发布出去的东西就尽量不要再想办法去修改他，那会带来更大的问题，所以每次发布前做tag，tag的东西是没有必要再去改的，要改就到下一版本再说；而针对当前持续开发的过程，尽量多开分支，每次修改代码建立一个分支，代码向主干的提交的过程中一定要做好code
> review，保障程序尽量少的出问题，这就是一个策略问题了。所以，我的观点是：没有release分支，而是一大堆针对不同时期release版本的tag；也没有debug分支，很多的分支，针对不同的情况建立不同的branch修改代码，控制好代码提交、合并的流程。
>
> 2009/12/7 raymond <shiqu...@gmail.com>
Fuzhou Chen
就我所知，Windows发布模式更接近于一段时间一个大release，本身没有debug版本的概念。每一个新的Windows版本开发完成之后就进入Sustained
Engineering阶段，会有一个专门的组负责维护的任务（这个维护期应当是10年），开发组总是马不停蹄做下一个版本。一旦一个版本已经进入维护阶段，那么它只会接受bug
fix，一般不会有大的变动，新功能一般也不会添加，除非出现当初XP
SP1安全问题和冲击波病毒那样已经在社会上招致大范围负面反响的情况。感觉上Windows在设计上的风格是要么不改，要么大改。
至于pre-release：我只能说我没感觉MS明确提过这个概念。我看到的结果是所有MSDN上得到的评估版本都是带版本号的，而且结构都差不多，所以它们应该是从某个daily
build的过程中选出来的若干个版本快照，本质上就是tag。
关于向上修正：从常理上考虑，如果低版本上出现了bug并且确实fix了，那无论如何都是要移植到高版本上的，不然就会出现非常荒谬的结果，比如我们在WS03上发现一个安全问题并修正了，如果不移植，那么Win7
发布出来后我们会“欣喜”地看到这个bug又出现了。但反过来，高版本向低版本的移植则不一定会发生，因为任何公司都希望人们去买高版本，如果低版本上什么问题都解决了，那用户就没有理由掏钱。只有一种情况例外，就是这个功能如果在低版本上不存在会直接影响高版本的工作，比如Win7的Active
Directory Web Services，如果Vista和WS03没有这个服务，则我们就不可能通过Active Directory
Powershell进行远程管理。这种情况他们会发布一个单独的升级包。
其实比起Windows这种MS之外谁也不知道的东西，我更推荐Raymond比对一下Linux
Kernel的开发模式。众所周知，Linux总是分devleopment release和stable
release两种版本：尾号奇数表示开发版，偶数表示稳定版，比如2.6.23和2.6.22。我没参与过Linux核心的开发，所以只能猜测，但是从git这个工具的功能上看我倾向于认为他们的开发应该存在非常频繁的porting/back-porting工作，因为git目前的分支管理功能极其强悍，可以近乎无限制地创建和取消分支，而且可以push的时候还可以选择性发布分支，在所有已知的版本管理工具中堪称翘楚。如果不是因为工作中大量存在这种需求，我相信Linus不会仅仅为了好玩而添加这个功能。
来，我也水一把，希望不会ban掉：跪求Linux高手解释……。
2009/12/7 raymond <shiq...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
sagasw
一般没有人把它称为release、debug版本区别的。
而且这种说法一般是针对桌面开发，web开发方式我不是很熟悉，但是应该修改的更频繁，好像也不存在什么stable版本，在线版本都是一直在修改运行。
相比来说，你提到的两个（甚至多个版本同时维护）都是很常见的，所以一般是某个defect被修改状态，开发者应该判断、team leader应该review是否需要多个版本都需要修改。
在某些情况下，这种defect可能是被放在下一个release，也就是当前release版本不需要重新做build，对于用户是以patch的方式来修改这个问题。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
Lei Yang
Jeff Chen
--
My Blog：http://jeffchen.cn
殷远超
红字那句表明您遇到的不只是debug和release的问题，是整个版本管理的问题。
做产品是个持续的过程，在这个过程里，产品总是不断的进步：就的bug被fix，新的bug不断产生，新的需求不断被加入。。。。
那么，在某个阶段我们需要发布realease版本的时候，realease和debug版本的关系是什么呢？
比如我们采用这种方式：
两个branch，一个是realease版本，一个是debug版本，那么就会出现这样的情况
release版本：可以给最终用户用的
debug版本，正在开发的，还在添加新功能的。
1. realease版本上发现了一个bug之后，我们fix掉bug，然后再仔细检查debug版本上当前是否还有这个bug（为什么仔细检查
呢？因为在realease版本被使用的过程中，debug版本已经进行了很多的改变，其code base和realsease都不一样了，同样的
bug fix的方式都可能不同）
--
殷远超 http://www.yinux.com
Fuzhou Chen
Lei Yang
Lei Yang
Lei Yang
raymond
1. 当一个bug在某个branch 1上被fix的时候，我们要决定，还有那些branch要fix？比如branch 2 要fix， 而
branch 2跟branch 1 相比可能变化很大了，比如别人加入了新的feature等，这就导致同一个bug 在branch 1 上的
fix方式跟在branch 2上fix的方式不同，如果有更多的需要fix的branch呢？这潜在的增加了工作量，并且增加了引入更多bug的风
险。
2. 如果上述第一点是事实上很多大型产品开发采用的方式，那么，可以想象，某个产品的同一个功能点也许需要很多人维护。比如某人维护branch
x,y,z 某人维护branch 1,2,3，这样的最终结果，这个产品还是一个产品吗？我觉得更像多个产品。
问题的本质是，现实中大型软件开发是采用上述方式吗？如果是，有什么的好的工具和好的方法，好的文章等来介绍如何保持每个branch的定义是足够清晰
的，比如哪些feature将被加入，会影响哪些功能，当前的bug列表，这些bug中哪些是和其他branch共享的，什么时候这个branch将被
merge到主线，等等。
谁能推荐这方面的好的书籍？
sagasw
另外，经常check in，nightly build，unit test都是保证branch合并以及代码修改完整的手段。
我如果是team leader，一定会推行这样的规则：遇到一个bug或者feature，先想想怎么测试，能写出test case，才能算fix或者finish。
对于其他的branch合并验证，那就用这些unit test来保证，而不是靠程序员的细心和眼睛看。
个人感觉你们现在开发的配置管理有些问题，你可以看看git或者linux开发配置管理的相关文章，你们项目再大，应该也就是跟linux差不多（当然会有非常巨大的可能性，但那种项目的配置估计已经不是常态，平常情况下不需要考虑）。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
tiger.lee
且是没有加上优化的，而Release版本则没有包含这些信息了，并且可能会加上优化。
我看楼上的一些分析好像是说到了分支管理和bugfix merge了。
或者楼主本意是想问这个，但标题对不上内容？
我对windows软件开发只有过少量经验，感觉VS就是这样来的。但在linux软件中，一般我们使用的都是不带调试信息的程序，但如果出现了问题，
可以下载对应的-dbg版本来进行调试。
如有不准，敬请指正。
Cheng, Long
见的一种做法是trunk作为稳定发布版本，所有的bug修改都在trunk上进行（或者
是一些小的功能改动）；需要几天以上开发时间的新功能都在分支dev branch上操
作（可以有多个不同的dev branch），然后在release之前将dev branch上的新功
能merge到trunk上，然后将对应的dev branch删掉；另一方面，trunk上的bug改动
也会定期反向merge到dev branch来。一个基本原则就是发布版本的bug改动只在
trunk上做。dev branch不需要对稳定性有很高的要求。当然了，一些show
stopper的bug是需要改了马上反向merge到dev branch的
raymond 写道:
zhijia zhang,.
Fuzhou Chen
fix的问题，因为debug和release版本其实都是从同一份代码里出来的。真的有问题，
那肯定是因为有不同分支。
我们公司对这个一般叫feature branch和release branch。
2009/12/8 raymond <shiq...@gmail.com>:
> 1. 当一个bug在某个branch 1上被fix的时候，我们要决定，还有那些branch要fix？
> 问题的本质是，现实中大型软件开发是采用上述方式吗？如果是，有什么的好的
> 工具和好的方法，好的文章等来介绍如何保持每个branch的定义是足够清晰
> 的，比如哪些feature将被加入，会影响哪些功能，当前的bug列表，这些bug中哪
> 些是和其他branch共享的，什么时候这个branch将被
> merge到主线，等等。谁能推荐这方面的好的书籍？
我觉得Raymond的看法有点过头了，我的经验中一般频繁merge的几个branch不可能都
处在活跃开发状态的，总会有一个是相对平稳的，只用于接受别的branch的修改。我们
公司的一个习惯是各个不同的组都有自己的feature branch，然后中央一个branch。每个
组只在自己的控制的目录下才进行频繁check in。每隔一段时间中央branch会从各个feature
branch取回最新的代码做一个总的build。当然这里的前提是：feature branch之间一般不
能有依赖关系。所以如果两个组的代码有明确的依赖关系，他们会共享一个feature branch。
还有一点是Raymond说的我认为已经不是技术问题，而是软件管理实践了。我的经验，
大型公司总有一群人专门负责决定哪些bug需要在哪些branch上给fix，而且这帮人一般
都是Lead或Manager那个级别的。在实践时，这些问题往往是通过两步走：首先是build
team会有自动merge的工具，其次是需要有各个组的developer和tester负责复查。最后
一般还有一个回归测试。比如我们公司每一次这种代码合并都会伴随一个大规模的全面
测试，来保证这次merge不会出问题。
至于书籍呢，我得说即使我现在身在美国也没看过有什么能在这些方面讲得很深的书，
多是属于泛泛而谈。我认为主要原因是这种东西和公司流程挂钩非常紧密，工程界的人
一般不便向外界透露；而且很多公司内部都有一些特殊的专用工具，比如微软传说中牛X
无比的Product Studio，就算有人写了书，别人也用不了。至于学术界呢，呵呵他们关注
的东西从来不在这里，不提也罢。
2009/12/7 Cheng, Long <long.x...@gmail.com>:
--
Lei Yang
raymond
1. 标题不合适，我确实想问的是需要release的branch和dev的branch的管理问题，而debug和release的区别诚如上面
tiger兄弟所言，只是有无调试信息。我们平时常常说release版本和debug版本，这样是不规范的呵呵。
2. 大家的观点都倾向于没有明确的方法和工具能够保证merge多个branch非常的方便而且不出错，一般就是人工分类，版本管理，回归测试等。
3. 我碰到的情况是，我们将要release一个版本，而目前dev版本还在开发新的feature，当一个dever发现bug后，他需要在两边同
时merge，而由于code base都不同，所以merge的时候不能简单的diff/patch，所以决定挺麻烦，而且确实有因为这些搞得
build break的情况。
4. 再问一个问题，check in之前要build 成功，并且pass 所有UT， 这耗费很多时间（几个小时），以前xuzhou曾经说过，可
以将UT跟某些code关联，这样更新某些code的时候只需要run相关的UT就行了，这个关系库感觉还是需要很大的精力的。在实际中，大家还有什么
方法呢？
看来，这个问题至少不是纯技术问题。
On 12月9日, 下午4时02分, Lei Yang <ynk...@gmail.com> wrote:
> 我现在的工作，就是一个为一个大型的软件工作。我相信这里所有的所有的人都听过， 它已经有将近26年的历史了。
> 我工作的是他的一下小产品，也有12年的历史。
> 我们使用不同版本不同分支的做法， 至今仍然工作的很好。 我现在负责一个模块（同时负责3个版本的维护 以及一个新版本的开发）。
> 我们的流程确实严格， 修改一个defect流程就要1周时间， 你需要提交到会上讨论，这也说明我们的产品defect不是很多，呵呵。
> 每当我们要check in代码段时候 我们都有大量的测试要跑，以保证尽量check in干净的代码。而且同事们Review code的时候会非常认真。
>
> 我觉得代码的分支管理也许是个问题， 也许真的会出现你的所说的分支之间差别非常大的情况。
> 但是我相信如果你的软件架构稳定，代码质量较高，还是可以很大程度上避免这种情况的。
> 而且随着时间的推移， 你的代码应该是不断进化的。 而且早期的版本不再维护，只要你处于良性循环当中，你的代码会最终趋于一致的。
>
> 2009/12/9 Fuzhou Chen <cppof...@gmail.com>
Fuzhou Chen
> 谢谢，看到了楼上的回复，两点感触：
> 2. 大家的观点都倾向于没有明确的方法和工具能够保证merge多个branch非常的方便而且不出错，一般就是人工分类，版本管理，回归测试等。
一般在我们公司所有的merge都是需要人工复查的。幸亏现在代码管理工具越做越好，
现在build team在自动merge时如果出现merge失败的情况，会标记代码并给相关的
owner发邮件，然后换一个目录接着merge。不过我不知道他们究竟是怎么做到的，
build的这东西是典型的似浅实深，没个三五年的不敢说入门。
> 3. 我碰到的情况是，我们将要release一个版本，而目前dev版本还在开发新的feature，当一个dever发现bug后，他需要在两边同
> 时merge，而由于code base都不同，所以merge的时候不能简单的diff/patch，所以决定挺麻烦，而且确实有因为这些搞得
> build break的情况。
> 4. 再问一个问题，check in之前要build 成功，并且pass 所有UT， 这耗费很多时间（几个小时），以前xuzhou曾经说过，可
> 以将UT跟某些code关联，这样更新某些code的时候只需要run相关的UT就行了，这个关系库感觉还是需要很大的精力的。在实际中，大家还有什么
> 方法呢？
这个我之前提过一次，我们公司的建的code coverage-case数据库就是
干这个的。不过单枪匹马维护这样一个数据库我感觉不太现实。如果没
有这个东西辅助，那么很大程度上就要靠测试组对产品的了解程度了。
一般我会按功能点把case分组，然后根据这一次的fix修改的功能点归类
跑对应的case。
我这做法处理上层代码bug的时候效果还不错，不过如果是修改出现在
非常基础的代码库时仍然有产生测试漏洞的危险，因为我们很难确定这
个修改会不会对其他的测试构成影响。我也知道我的一些同事无论怎样
都是所有测试统统跑一遍，就是求个放心。
顺便八卦一个：我们这边每次check in一个客户请求的fix之前标准的测
试流程需要三个星期。所以区区几个小时在我看来实在是很高效了。 :)
>
> 看来，这个问题至少不是纯技术问题。
>
> On 12月9日, 下午4时02分, Lei Yang <ynk...@gmail.com> wrote:
>> 我现在的工作，就是一个为一个大型的软件工作。我相信这里所有的所有的人都听过， 它已经有将近26年的历史了。
>> 我工作的是他的一下小产品，也有12年的历史。
>> 我们使用不同版本不同分支的做法， 至今仍然工作的很好。 我现在负责一个模块（同时负责3个版本的维护 以及一个新版本的开发）。
>> 我们的流程确实严格， 修改一个defect流程就要1周时间， 你需要提交到会上讨论，这也说明我们的产品defect不是很多，呵呵。
>> 每当我们要check in代码段时候 我们都有大量的测试要跑，以保证尽量check in干净的代码。而且同事们Review code的时候会非常认真。
>>
>> 我觉得代码的分支管理也许是个问题， 也许真的会出现你的所说的分支之间差别非常大的情况。
>> 但是我相信如果你的软件架构稳定，代码质量较高，还是可以很大程度上避免这种情况的。
>> 而且随着时间的推移， 你的代码应该是不断进化的。 而且早期的版本不再维护，只要你处于良性循环当中，你的代码会最终趋于一致的。
>>
>> 2009/12/9 Fuzhou Chen <cppof...@gmail.com>
>>
>> > Cheng Long兄这个解释靠谱。如果仅仅是谈有没有调试信息的话通常不会有merge
>> > fix的问题，因为debug和release版本其实都是从同一份代码里出来的。真的有问题，
>> > 那肯定是因为有不同分支。
--
oliver yang
> 谢谢，看到了楼上的回复，两点感触：
> 1. 标题不合适，我确实想问的是需要release的branch和dev的branch的管理问题，而debug和release的区别诚如上面
> tiger兄弟所言，只是有无调试信息。我们平时常常说release版本和debug版本，这样是不规范的呵呵。
一般常见的叫法还是“稳定版本”和“开发版本”。
> 2. 大家的观点都倾向于没有明确的方法和工具能够保证merge多个branch非常的方便而且不出错，一般就是人工分类，版本管理，回归测试等。
> 3. 我碰到的情况是，我们将要release一个版本，而目前dev版本还在开发新的feature，当一个dever发现bug后，他需要在两边同
> 时merge，而由于code base都不同，所以merge的时候不能简单的diff/patch，所以决定挺麻烦，而且确实有因为这些搞得
> build break的情况。
这种merge我们内部的叫法是backporting.
例如 Solaris的稳定版本是Solaris 10 update 9， 开发版本是OpenSolaris，
OpenSolaris是从Solaris 10分支出来的。
当发现一个新bug时，
1. bug在OpenSolaris里发现的，一般要现在OpenSolaris修复并测试，然后提交代码后，再backporting到Solaris 10里。
这种backporting基本上因为codebase差异很大，需要完整的新的一轮合并patch和测试。
2. 也有可能一个bug只在Soalris 10或者OpenSolaris里单独存在，所以bugtraq系统支持Multiple
release/branch的功能。
这时只需要独立的解决。
3. Solaris/OpenSolaris的build, 回归测试完全是独立的，每个build的测试都是自动化的。
> 4. 再问一个问题，check in之前要build 成功，并且pass 所有UT， 这耗费很多时间（几个小时），以前xuzhou曾经说过，可
> 以将UT跟某些code关联，这样更新某些code的时候只需要run相关的UT就行了，这个关系库感觉还是需要很大的精力的。在实际中，大家还有什么
> 方法呢？
>
> 看来，这个问题至少不是纯技术问题。
在OpenSolaris里，和代码相关的测试是提交patch之前做的。
提交之后，每两周，Solaris会产生一个build，每个build都会经过完整的回归和集成测试，这是完全自动化的。
>
> On 12月9日, 下午4时02分, Lei Yang <ynk...@gmail.com> wrote:
>> 我现在的工作，就是一个为一个大型的软件工作。我相信这里所有的所有的人都听过， 它已经有将近26年的历史了。
>> 我工作的是他的一下小产品，也有12年的历史。
>> 我们使用不同版本不同分支的做法， 至今仍然工作的很好。 我现在负责一个模块（同时负责3个版本的维护 以及一个新版本的开发）。
>> 我们的流程确实严格， 修改一个defect流程就要1周时间， 你需要提交到会上讨论，这也说明我们的产品defect不是很多，呵呵。
>> 每当我们要check in代码段时候 我们都有大量的测试要跑，以保证尽量check in干净的代码。而且同事们Review code的时候会非常认真。
>>
>> 我觉得代码的分支管理也许是个问题， 也许真的会出现你的所说的分支之间差别非常大的情况。
>> 但是我相信如果你的软件架构稳定，代码质量较高，还是可以很大程度上避免这种情况的。
>> 而且随着时间的推移， 你的代码应该是不断进化的。 而且早期的版本不再维护，只要你处于良性循环当中，你的代码会最终趋于一致的。
>>
>> 2009/12/9 Fuzhou Chen <cppof...@gmail.com>
>>
>> > Cheng Long兄这个解释靠谱。如果仅仅是谈有没有调试信息的话通常不会有merge
>> > fix的问题，因为debug和release版本其实都是从同一份代码里出来的。真的有问题，
>> > 那肯定是因为有不同分支。
--
Cheers,
Oliver Yang
Twitter: http://twitter.com/yangoliver
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
An OpenSolaris Developer
raymond
我说几个小时是build的时间，每天准备下班的时候开始build，然后跑UT，花费几个小时，这样下班都晚了，呵呵。而且现在feature越多，
UT也开始多起来，
On 12月10日, 上午3时56分, Fuzhou Chen <cppof...@gmail.com> wrote:
> 2009/12/9 raymond <shiqu...@gmail.com>:
raymond
On 12月10日, 下午12时26分, oliver yang <yangoli...@gmail.com> wrote:
> 2009/12/10 raymond <shiqu...@gmail.com>:
Fuzhou Chen
那么手工管理一个Excel表格总是好的。
我好奇的是Raymond兄为什么每次build就要花几个小时，这听起来像是要从头做
一次clean build。但我的经验里这一般是不必要的，因为一天之内我能改的代
码总会局限在很有限的几个目录里，所以我只需要在下班之前保证我改的那几个
目录没有编译错误，剩下的就是起一个自动化脚本，从clean build到跑test一次
做完，第二天上班看结果。
真要遇上Raymond兄那种全程监控build的情况我估计只有一种，就是你的代码所依
赖的其他部分每天都在不停地改接口定义。但若真是如此我认为你呆在旁边看着其
实也解决不了问题，唯一的解决方案应该是和同事老板协调。
可否说明一二？
2009/12/10 raymond <shiq...@gmail.com>:
oliver yang
> 每两周一次感觉太长，我们现在每天一次感觉太频繁，这还是蛮纠结的问题。
Solaris 每两周出一个正式的build,做彻底的测试。
每天做一次nightly build,运行一个简单一些的测试。
做到这点需要从build到安装机器，配置，运行测试，测试结果的发布都是自动化的，不需要人工干预才可以。
