Thanks for sharing the thoughts, Evans. I was thinking of those reasons when branched it out: 1. there are no more inputs for 1.3.0 release BOM. So I assume the community has agreed on the scope of 1.3.0. 2. allow users to contribute patches beyond 1.3.0's scope without putting their work in queue while release is inprogress. 3. there should be only a small set of patches need to be merged back to master. In BIGTOP-3063, there are 10 blocking JIRA tickets, which should reflect 10 patches, required for 1.3.0. There might be more when doing the real job, but should be doable efforts to merge back.
I fully agree the points Evans mentioned, while one thing is we need to branch out on a proper ground. In my view RC might a little bit late because of #2. Given this specific case (10 blockings JIRAs for 1.3.0) I ran a bit faster. :) Eager to hear you folks inputs. :) 2018-08-16 14:03 GMT+08:00 Evans Ye <[email protected]>: > I saw Jun He branched off branch-1.3. This may due to I suggested him to > proceed on the release steps[1]. > > Take this chance I'd like to discuss when's the right time to branch off > release. > > I prefer not to actually branch off too early cause we still need to work > on several patches for 1.3 release. If we branch off this early then we > need to cherry-pick patches between branches. Although that's also doable, > we need to spend extra effort to maintain up coming patches for the master > and 1.3 branch. > > My experience previously doing release is to branch off when I need to > release a RC. RC may go from RC1 to RC3 or else. So for patches coming > after RC, I'll pick them into release branch only if it fixes the issue for > release. Of course, this way works just because we've relatively smaller > scale of patches to deal with. For those large projects such as Hadoop and > HBase, strict branch control prevents various feature interferes each > other. > > Evans > > [1] https://cwiki.apache.org/confluence/display/BIGTOP/How+to+release >
