Hi All, +1 for me.
What’s proposed look like the development flow of llvm https://github.com/llvm/llvm-project <https://github.com/llvm/llvm-project> They are using master for development and release branches for stabilization. Greetings, Roy > Op 23 apr. 2020, om 18:20 heeft Alexander Broekhuis <[email protected]> > het volgende geschreven: > > Op do 23 apr. 2020 om 09:10 schreef Pepijn Noltes <[email protected] > <mailto:[email protected]>>: > >> Hi All, >> >> +1 for me. >> >> On Thu, Apr 23, 2020 at 6:34 AM Alexander Broekhuis >> <[email protected]> wrote: >>> >>> I'm not against this. But would like some more info on how we are going >> to work with this. >>> >>> What is your proposal wrt feature, bugfix and release branches? >>> One concern I have is that last one. With a dev/master split, a release >> branch can be used to prepare a release to master, while dev is used to >> continue merging new features to. >>> How should we do that now? >> >> Maybe I am oversimplifying this, but IMO almost everything will be the >> same, expect that there is no master branch pointing to the latest >> release. >> So instead of creating a tag, merging to master and then merging to >> develop. The last part can be dropped. >> > > Sounds good enough for me. Perhaps this is me lacking some git knowledge, > but the tag is on the branch, and the branch can be deleted later. Is that > a problem? Just asking to be sure. I think it is important to be able to > continue on master with new development. > > >> >> If we follow our release procedure [1] we also use a release branch >> and only the "Merge to master and create GIT tag" needs to change. >> I rather have that we move forward and when updating the website also >> update the "Merge to master and create GIT tag" of the release >> procedure. >> >> If any more documentation is needed we can address this on a later date. >> > > What's the rush with this? Let's do it properly at once. It is not like we > are having any problems at the moment. Also IMHO, I don't think what I am > requesting is anything difficult/strange. > > Like I said, I am in favour, but just prefer to do it in one go... > > >> >> [1] https://celix.apache.org/contributing/releasing.html >> >>> >>> Before doing the actual change, can you draft up a developer page for it? >>> >>> Because of this, for now a -1. Will gladly change to a +1 if things are >> clear! >>> >>> -- >>> Met vriendelijke groet, >>> >>> Alexander Broekhuis >>> On 22 apr. 2020 19:22 +0200, Roy Lenferink <[email protected]>, >> wrote: >>>> Hi all, >>>> >>>> I'd like to propose the idea of using the 'master' branch as our >> development branch. Why? >>>> - ASF releases are promoted through the ASF mirroring system. Our >> website is built on top of this >>>> allowing the user to select a mirror for downloading the release. >> Cloning the git repository is not >>>> the first thing a user does. Even if users plan to use the git >> repository they can use a specific tag. >>>> - The ASF allows committers to use a so-called .asf.yaml file [1] for >> changing repository settings. >>>> However, changes to this file are only propagated when made on the >> master (or trunk) branch. >>>> >>>> IMO our current workflow with develop/master just adds extra >> complexity. Other ASF projects are >>>> using the master branch as their development branch as well, e.g. >> Spark [2], Dubbo [3], Flink [4] & >>>> HBase[5]. >>>> >>>> If no objections within 72 hours I'll merge the 'develop' branch to >> our 'master' branch, update the >>>> current open pull requests to have 'master' as base branch, open a >> ticket to remove branch >>>> protection for the develop branch & update the website to point to the >> master branch for changes >>>> instead of the develop branch. >>>> >>>> See also [6] for a short discussion on this topic already. >>>> >>>> Best, >>>> Roy >>>> >>>> [1] https://s.apache.org/asfyaml >>>> [2] https://github.com/apache/spark >>>> [3] https://github.com/apache/dubbo >>>> [4] https://github.com/apache/flink >>>> [5] https://github.com/apache/hbase >>>> [6] https://github.com/apache/celix/pull/202#issuecomment-616429007 >> > > > -- > Met vriendelijke groet, > > Alexander Broekhuis
