Hi all: The current dev-1.0.0 branch has passed regression testing. Currently remaining PRs and Issues to be merged:
* https://github.com/apache/incubator-doris/labels/dev%2F1.0.0 The new branch dev-1.0.1 will be created. And the labels for dev/1.0.0 and dev/merged-1.0.0 will no longer be used, use dev/1.0.1 and dev/merged-1.0.1 instead All backlog commits can be found here: * https://github.com/apache/incubator-doris/pulls?q=is%3Apr+is%3Aopen+label%3Adev%2Fbacklog Some of them will be cherry-picked into branch dev-1.0.1 -- 此致！Best Regards 陈明雨 Mingyu Chen Email: chenmin...@apache.org At 2022-02-24 13:09:37, "陈明雨" <morning...@163.com> wrote: >Let me re-state the complete process. >For example, if we are currently ready to release 1.0, I would create a dev >branch with a name such as dev-1.0.x. For example, I would create the first >branch, dev-1.0.0, and create the corresponding labels: dev/1.0.0, >dev/backlog, and dev/merged. >All new commits are still committed to the master branch as before, and then >merged into master after review-approved, but when merged, they must be tagged >with the corresponding dev label, such as dev/1.0.0 or dev/backlog, where >dev/1.0.0 means the PR needs to be merged into the dev-1.0.0 branch, and >dev/backlog means the PR is not merged into the dev-1.0.x branch. > > >So, all commits will still be merged into the master branch, as usual. And we >need to do the following additional things: >1. every day, we filter out the commits that correspond to the label of the >current dev branch (e.g. dev-1.0.0). after multiple people confirm that these >commits are to be merged into dev-1.0.0, the designated person will manually >merge these commits into dev-1.0.0. after merging, we need to label these PRs >dev/merged. >2. The purpose of the dev branch is to "isolate unintended code risks". For >example, if the first week we focus on fixing bugs in the join operator, then >the first week of dev-1.0.0 may only accept join-related bug fixes. In the >second week, when the join issue is fixed, the dev-1.0.1 branch will be >created and will start accepting commits that were previously tagged as >backlog. At this point, you need to remove the backlog tag from the PR and add >the tag of dev/1.0.1. >3. for example, at dev-1.0.3, we think we are ready to release, so we will do >a release based on this branch. >4. Assuming that the next release is 1.1, we might create branch dev-1.1.0 >directly from the latest master branch, which would include all the previous >commits that were not merged into 1.0, and then repeat the previous operation. > > >=================================== >让我重新说明下完整的流程： >比如我们当前准备发布 1.0 版本了，那么我会创建 dev 分支。dev 分支的命名规则如：dev-1.0.x。比如我会创建第一个分支 >dev-1.0.0，并且会创建相应的 label：dev/1.0.0，dev/backlog 和 dev/merged >所有的新提交依然和以前一样提交到 master >分支，经过review-approve后合入master。但合入时，必须打上对应的dev标签，如dev/1.0.0 或 >dev/backlog。其中dev/1.0.0 表示该PR需要合并到 dev-1.0.0分支中。而dev/backlog 则表示该PR不合入到 >dev-1.0.x 分支中。 > > >所以，所有提交依然会和往常一样，全部合入master分支。而我们需要额外做如下事情： >1. >每天筛选出当前dev分支（比如dev-1.0.0）对应标签的commit。经多人确认这些commit要合入dev-1.0.0后，由指定人选手动将这些commit合入dev-1.0.0，合入后，需要给这些PR打上标签 > dev/merged >2. dev 分支的作用在于“隔离预期外的代码风险”。比如第一周我们重点在修复join算子的bug，那么第一周的 dev-1.0.0 >版本可能只接受join相关的bug修复。其他的commit都会标记为 >backlog。而第二周join问题修复完成了，可能会创建dev-1.0.1分支，开始接收之前标记为backlog的commit。此时，需要将PR的backlog标签删除并增加 > dev/1.0.1 的标签。 >3. 比如到 dev-1.0.3 时，我们认为具备发版条件了，那么会基于 这个分支进行release。 >4. 假设接下来发布 1.1 版本，那可能会直接从最新 master 分支创建branch dev-1.1.0，这样相当于包含了之前所有未合入到 1.0 >版本的commit，然后重复之前的操作。 > > > > >-- > >此致！Best Regards >陈明雨 Mingyu Chen > >Email: >chenmin...@apache.org > > > > > >在 2022-02-24 11:14:48，"ling miao" <lingm...@apache.org> 写道： >>> When a PR labeled with "dev/backlog" is explicitly to be merged into >>a dev branch, remove the "dev/backlog" label and add the dev label of the >>corresponding branch. >> >>Are you referring to the dev branch as master branch ? >>So if the PR that does not belong to 1.0 , can it be merged into master >>directly? >> >>Secondly, if a PR belongs to version 1.0. >>So when merging this PR, do you have to merge it into the master >>branch and *manually >>pick *it into the 1.0 branch? >> >>Ling Miao >> >>41108453 <41108...@qq.com.invalid> 于2022年2月23日周三 23:54写道： >> >>> +1 >>> >>> >>> >>> >>> >>> ------------------ Original ------------------ >>> From: 陈明雨 <morning...@163.com> >>> Date: Wed,Feb 23,2022 11:44 PM >>> To: doris-dev <dev@doris.apache.org> >>> Subject: Re: [DISCUSS] Weekly build and prepare for releasing 1.0 >>> >>> >>> >>> Hi All, >>> At present, the main features of version 1.0 are in the final stage of >>> development. Stability and bug fixing work will be carried out later. >>> We are currently encountering some problems: >>> 1. some features that have not been fully validated have been merged in, >>> affecting the testing of existing features, resulting in problems that have >>> not been converged. >>> 2. have been unable to maintain a stable baseline version, resulting in >>> uncontrollable release cycle. >>> >>> >>> In response, I will take the following steps to ensure that the problem is >>> converged and manageable. >>> >>> >>> 1. PR tagging >>> All PRs must be labeled with the following tags. >>> For example, dev-1.0.0 for the first week and dev-1.0.1 >>> for the second week. >>> After the branch is created, the branch will only >>> selectively merge in PRs tagged with "dev/1.0.0". >>> All subsequent PRs must be labeled as follows. >>> - dev/1.0.0: Indicates that >>> this PR needs to be merged into the dev-1.0.0 branch. >>> - dev/backlog: Indicates that >>> the PR is not to be merged into any dev branch at this time. >>> When a PR labeled with "dev/backlog" is explicitly to >>> be merged into a dev branch, remove the "dev/backlog" label and add the dev >>> label of the corresponding branch. >>> >>> >>> 2. PR merge principle >>> After a PR Approve, it should, in principle, stay at >>> least one day before it is merged in, so that other reviewers can make >>> possible confirmation. >>> If you need to merge quickly, please comment in the PR >>> to explain the reason. >>> All PRs must have a clear dev label before merging in. >>> >>> >>> The final Release version will be generated from the dev branch. >>> I will follow up and push for this to happen, if others would like to >>> participate in this effort, or have suggestions or comments, please feel >>> free to discuss. >>> >>> >>> >>> -- >>> >>> 此致！Best Regards >>> 陈明雨 Mingyu Chen >>> >>> Email: >>> chenmin...@apache.org
