Hi Chris, Agree.
Canceling RC version will waste the time of both reviewers and release managers... Is there some guide or formal steps for "code stabilization"? Current, we check out a new branch "rel/<major_version>" once we thought the wanted features are implemented (except for the postponed features), Then we begin to start the release process, and do not put any new features into the branch. At least for this release (v0.11.0), I followed the above steps. I think it is not very hard to determine when to check out a new branch (e.g., once we make a consensus), but it is hard to know when to start a RC release, as we do not know whether there are critical bugs in the RC version. For example, in this release process, I thought RC1 was fine enough but Zesong told me there were some critical bugs and then Jialin told me the same thing when releasing RC2... I am also rethinking why there are so many bugs that not be found in our UT/IT, etc.. In our previous release processes, this case is rare. (Though we have many RC version, but many of them are caused because something like LICENSE, incorrect files included, etc..) Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Christofer Dutz <[email protected]> 于2020年11月20日周五 下午7:19写道： > Hi all, > > in the past many RCs had to be cancelled probably because cutting a > release is sort happening by taking a snapshot at a given time and > instantly trying to release it. > > Given the amount of commits I see in this project every day, perhaps it > would make sense to announce the next release process being started at a > given date & time and to cut a release branch on that date. This way anyone > has the chance to finish features that should go in this release … on the > release branch we can then test and check that everything’s fine and works > as expected. As soon as the release branch is stable, that’s released. > > In the code-stabilization phase I would suggest to no include any new > features or improvement … just fixes for problems that are found. > > This way the project can continue development without any issues and we > can stabilize the release before cutting the RC. > > Perhaps this way we can reduce the amount of cancelled RCs > > The main problem I see here, is that for example I have stopped doing > early RC validation for IoTDB as in the past a lot of RCs I invested time > in reviewing were cancelled and updated with a big number of changes, which > forced me to do my review in full extent again. This sort of made me more > cautious and so now I wait 2-3 days before starting to do it. > > Just my thoughts … > > Chris >
