Hi, If we decide to release cluster version along with master, it seems useless to checkout out a cluster_release branch.
But for the operation of merging the cluster_new branch into the master branch, I will have two questions if we finally decide to do that: 1. I am concerned that some stand-alone version changes that do not involve distributed module will directly cause distributed module's compilation to fail or CI to fail, so many stand-alone colleagues will also have to focus on distributed module’s CI, or distributed module's colleagues will have to focus on each PR that causes distributed module’s CI to fail, how will we handle this then? 2. Since distributed module's changes are likely to be frequent in the future, it is inevitable that some stand-alone versions of the code will be changed. If every distributed module’s PR involving changes to the stand-alone version needs to be reviewed by colleagues of the stand-alone version, whether this will cause a waste of human resources? Do we need a cluster_new(cluster_develop) branch to maintain daily distributed development, and then merge to master periodically, so that stand-alone colleagues can only focus on the periodic PR changes to stand-alone version? Thanks _______________ XinYu Tan > 在 2020年10月13日，上午10:12，Tian Jiang <[email protected]> 写道： > > My suggestion would be: > First, we will decide some tests which must be passed before cluster releases. > Then, after passing such tests, we merge `cluster_new` into `master`. > Next, any new PRs to `master`, related to distributed logic or not, must also > pass these tests. > Finally, hopefully, the cluster version will released along with 0.12.0. > > > Tian Jiang > > > On 10/13/2020 09:54，[email protected]<[email protected]> wrote： > Hi， > > I think that only maintaining master branch is also good, but how to release > first cluster version? > > The cluster branch is always influenced by master branch now. > > May we need to checkout a new branch to release the first version? > > > > Thanks. > > Chao Wang > BONC Ltd > > > From: Jialin Qiao > Date: 2020-10-12 20:38 > To: dev > Subject: Re: [DISCUSS]The cluster version management > Hi, > > I suggest starting to merge the cluster_new branch to master and maintaining > the cluster as a module. > Maintaining two branches is hard... > > Thanks, > -- > Jialin Qiao > School of Software, Tsinghua University > > 乔嘉林 > 清华大学 软件学院 > > -----原始邮件----- > 发件人: "[email protected]" <[email protected]> > 发送时间: 2020-10-12 16:19:30 (星期一) > 收件人: dev <[email protected]> > 抄送: > 主题: Re: Re: [DISCUSS]The cluster version management > > Hi Houliang, > > Good idea! > > I also think we need to accelerate the development of cluster version. > > Now the cluster release branch is always update with master branch which is > not stable. > > We need to force more on stability than feature, and we should add switch for > new feature to be disabled util we have tested it. > > Like Tian Jiang says, maybe we will release cluster together with master > later, but for the first release we need a cluster_develop and > cluster_release branch. > > We should stop merge feature to the cluster_release branch when we decide to > release. > > > > Thanks. > > Chao Wang > BONC Ltd > > > From: Tian Jiang > Date: 2020-10-12 15:43 > To: dev > Subject: Re: [DISCUSS]The cluster version management > This is an interesting suggestion. I thought that once `cluster_new` is > merged into `master`, there would be no more `cluster_new`. Cluster will be a > normal module just like jdbc or CLI, and developments should be based on > `master` then, instead of a branch separately for the cluster version. And I > doubt if we will release cluster version separately, since it may come > naturally together with the releases from `master`. > > > Best, > Tian Jiang > > > On 10/12/2020 15:28，Haimei Guo<[email protected]> wrote： > Looks good! > > On Mon, Oct 12, 2020 at 12:23 PM Houliang Qi <[email protected]> wrote: > > Hi all, > > > I’d like to start a discussion about the cluster version management: > > As someone mentioned that there should be a develop branch and a release > branch[1]. The develop branch is used to submit the latest development, and > the release branch is used for the functions that need to be released in > the latest release. > > At the same time, I hope that the development of cluster can also have two > branches: cluster_develop branch and cluster_release branch. > > The cluster_develop branch is used to merge the stand-alone version of the > develop branch code and the latest development of the cluster. > > The cluster_release branch is used to release some of the latest features. > Only the functions that need to be released are allowed to be merged into > the cluster_release branch, or to fix some bugs. Other newly developed > functions are not allowed to be merged into the cluster_release branch. > After cluster_release has been fully tested, it can be released. > > Regarding the latest release, I would like to check out a cluster_release > branch after the cluster_premerge branch merges into the master (develop), > and then the master branch merges into the cluster_new (cluster_develop) > branch. > > And I think the new functions do not have beed tested or need more than > one month to tested should be switch off when release the cluster version. > > Does anyone have some ideas about this? > > > [1] > https://lists.apache.org/thread.html/rf7dce8d4cfcf4001feeba139cc897d6b40a1741e06ef87aabd56d8c9%40%3Cdev.iotdb.apache.org%3E > > > > > Thanks, > --------------------------------------- > Houliang Qi > >
