# Development Process Recommendation: Adopt a develop Integration Branch **URL:** \ **Category:** Development\ **Created:** [March 16, 2026, 3:34pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220 "2026-03-16T15:34:43Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\ **Post date:** [March 16, 2026, 4:49pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/2 "2026-03-16T16:49:00Z")
This has already been discussed before. We use our _master_ branch as a _develop_ branch. Bigger changes can use a _geps_ branch if required so as not to break the _master_ branch. I think that the problems that you describe could be solved just as well by merging PRs into the _master_ branch on a more regular basis. Currently PRs for enhancements are required to wait for 3 weeks minimum to wait for comments from developers. After this time they can be reviewed and merged if there are no objections. If there are any objections then the resolution process is followed. At the moment I tend to wait for a few months before a release before reviewing and approving (or rejecting) PRs in a batch. The next feature release (v6.1) is scheduled for October 2026. This timescale is always up for review and I started a discussion with Chris Horn about it in the past. I seem to remember that we were going to assign a status to each PR (perhaps with a label) and then send a reminder (perhaps using GitHub actions) when a PR was ready for review. --- _[View the full topic](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220)._