Hi Julian and others, there's no need to rename and create some zombie "master" ... for PLC4X we decided to create deveop and simply stopped pushing to master (The Jenkins job of IoTDB even has the hook to send emails if someone pushes to master commented out). I would suggest to simply create "develop" from master HEAD and to fork a release-branch (if wanted) from develop then. As soon as the release is done, you would merge the release branch with "master" and then master would always post to the latest released version.
And regarding releasing without being a committer ... this could be doable, but could be problematic. The maven-release-plugin does GIT operations automatically (including pushing) ... You can prevent it from pushing by providing the "-DpushChanges=false" option. But I'm not sure if the git repo defined in the "scm" tag of the root pom will interfere. Assuming the scm settings will not interfere, I could imagine this: - The non-committer would make sure he has checked out an up-to-date fork of IoTDB - He does the release on that fork - He creates a PR from after performing the release However I would really suggest to simply make the RM at least a committer of your project ... after all: Creating a release is sort of as contributed as you can get ;-) Chris Am 08.07.19, 14:33 schrieb "Julian Feinauer" <[email protected]>: Hi Xiangdong, that sounds reasonable and can be done. I think first, some preparation has to be done so or so. There already has been a discussion about the branching model to used [1]. Although master and develop are kind of the same thing I would advice to totally stick to the naming convention named here [2]. This means that we would rename the master to develop (and master would currently point to "nowhere" until we have the first release). So I suggest to start a formal VOTE for the rename. I can do that but I think its uncommon four non comitters, so if you agree, you could do that. After the rename we could start creating a "rel/0.8" branch where we can start working on release stabilization phase. Julian [1] https://lists.apache.org/x/thread.html/7d3b04a1518cc76f72bcb66c94bd24e99d8e6e3ad41f39a202d3f477@%3Cdev.iotdb.apache.org%3E [2] https://datasift.github.io/gitflow/IntroducingGitFlow.html Am 08.07.19, 13:54 schrieb "Xiangdong Huang" <[email protected]>: Hi Julian, Thanks for your suggestion. We are trying to nominating new contributors as committers now... Actually we really need experienced guys to guide us the release process. If we cannot solve the committer identity in a short time, how about guiding us and I can follow your instruction. It is also a good chance to let us know how to release a project in practice. I think it is important to let more persons know how to release in this community. If so, considering the contribution you will take, I think you are the actually release manager. :) Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Justin Mclean <[email protected]> 于2019年7月8日周一 下午5:39写道： > Hi, > > > The only problem is that I am no committer so I would need the support > of someone from the PMC to help with release branch / release tags. I'm > unsure if the rest (nexus and stuff) works as I'm PMC elsewhere. > > Anyone can be the releasee manager, but not being a committer may make it > a little difficult. You would need to make PR to fix any of the issues re > license and notice file and to update update the readme for example. You > also couldn’t put the release in the correct spot to vote on it, I’m not > 100% sure how you could get around that. While it’s probably not impossible > to do, I know of no other releases that has been made by someone who is not > a committer (and they are usually (P)PMC members). > > Thanks, > Justin
