# 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:** 16\ **Page:** 1
**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\ **Post date:** [March 16, 2026, 3:34pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/1 "2026-03-16T15:34:43Z")
I’m trying to understand our development flow. It seems like we have a backlog of around 40 PR enhancements that go back more than a year, since Gramps 6.0 was released. [https://github.com/gramps-project/gramps/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse](https://github.com/gramps-project/gramps/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse) Many developers have been creating PRs for the last year. This causes a few problems: - PRs cannot build on one another, at least not easily - The full release doesn’t get sufficient testing; we could have been testing all of these for the last year - Development stagnates between major releases - Developers forget about and lose interest if their contributions sit for a long time What can we do? ## Recommendation: GitFlow Variant with a `develop` Branch ### Branch Structure ```python master ──●────────────────────────────●──────────► (stable, tagged releases) │ │ maintenance/60 └──●──●──●──●──► │ (6.0.x bug fixes) │ maintenance/61 └──●──●──► (6.1.x bug fixes, future) develop ──●──●──●──●──●──●──●──●──●──●──► (continuous next-version PRs) ``` ### How It Works 1. **PRs target `develop` immediately** — they get merged, tested, and can build on each other. 2. **When a major release is ready** , cut a `maintenance/gramps61` branch from `develop`, tag a release, and merge to `master`. 3. **Bug fixes** go to the relevant `maintenance/` branch and are cherry-picked back to `develop`. 4. **Database/plugin breaking changes** land in `develop` freely, since `develop` always represents an unreleased version. ### Benefits Over Current Process | Problem | Solution | | --- | --- | | PRs can’t build on each other | All PRs merge to `develop` continuously | | Release undertested | `develop` accumulates months of integrated testing | | Stagnant development | Contributors get immediate feedback and merges | ### Handling Dependency Isolation Since `develop` always represents the _next_ incompatible release, isolation is preserved by definition — `maintenance/gramps60` and `develop` are fully independent code lines. **Policy:** - **Breaking DB/plugin changes** → `develop` only - **Bug fixes** → `maintenance/` branch first, then cherry-pick to `develop` - **PRs must declare their target** : fix (→ `maintenance/`) or feature (→ `develop`) ### Optional Addition: Time-Based Release Train A common reason PRs pile up is that “when is the next release ready?” is ambiguous. A **time-based release train** (e.g., every 6 months, cut a release from `develop`) removes that ambiguity and gives contributors a predictable merge target. Projects like Python, Firefox, and GNOME use this model successfully. The GitLab and CPython projects are good references for real-world policies. ---
**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. ---
**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\ **Post date:** [March 16, 2026, 5:29pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/3 "2026-03-16T17:29:57Z")
> [@Nick-Hall](#): > > 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. Yes please! That would allow development and testing to continue without further waiting. And I think could have a large impact on major release timing. > 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. In my opinion that is too much time between finishing a PR and reviewing, and way too much time between releases. I know that it takes time to review, but there are other developers that can help, and with AI-driven reviews, the process could be made much easier and faster. There are 40+ non-controversial enhancements that justify a release now, and none of them require a schema change or plugin change. If we relax the constraint that we don’t allow “enhancements” in a maintenance branch, we could proceed faster without having to wait almost 2 years to get those contributions out. Please let us know how we can help. ---
**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\ **Post date:** [March 16, 2026, 5:31pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/4 "2026-03-16T17:31:44Z")
I’ll also add that the next version of gramps-web could benefit from getting the current set of open PRs available as 6.0.8 or 6.1, whichever. ---
**Author:** ![codefarmer](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@codefarmer](https://gramps.discourse.group/u/codefarmer)\ **Post date:** [March 16, 2026, 10:08pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/5 "2026-03-16T22:08:24Z")
It ought to be acknowledged that a lot of this activity is thankless and on behalf of the community, I’d like to thank @Nick-Hall (gramps) and @GaryGriffin (addons-source) for doing the work. We should also celebrate that the time between patch releases has gone down, and the number of patch releases is also up! 🎉 > [@Nick-Hall](#): > > 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. While I wasn’t aware of the three-week policy, I will keep that in mind. I have one or more PRs open longer than 3 weeks, but I hesitate to consider a lack of comments as approval. I have had reviews from @dsblank (thanks!) but even then I would not want to self-merge PRs. Good practice suggests someone other than the author merge it (in fact, I don’t even have write access to the repos, and so far it has not been a hinderance). Another thing that adds to ambiguity around open PRs is not knowing which release they are being targeted to. This applies to the author of the PR, and also our users who find that issue in MantisBT. The authors typically know which release it should go into, but can’t set that field in MantisBT. So while we under-use the `Target Version` field in MantisBT, I notice that the `Milestone` field in GitHub has seen more use recently. It would be great if we use both consistently, but if it turns out to be burden and we can use only one, I suggest `Target Version` because it is tied to MantisBT issues (the exception being issue-less PRs). Tagging issues properly can generate the Roadmap/Summary pages in Mantis, and anyone can get an instant view of the roadmap. > [@dsblank](#): > > …with AI-driven reviews, the process could be made much easier and faster. Yes, please! Is Copilot Review enabled in `gramps` and `addons-source` review? It is enabled in the gramps-web-api repo. ---
**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, 10:20pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/6 "2026-03-16T22:20:01Z")
> [@dsblank](#): > > If we relax the constraint that we don’t allow “enhancements” in a maintenance branch, we could proceed faster without having to wait almost 2 years to get those contributions out. I think that we should keep maintenance releases limited to bug fixes only, but we can increase the frequency of feature releases. The current policy gives us the flexibility in the interval between releases. > [@codefarmer](#): > > While I wasn’t aware of the three-week policy, I will keep that in mind. I have one or more PRs open longer than 3 weeks, but I hesitate to consider a lack of comments as approval. It’s usually a minimum of 3 weeks in the _master_ branch and 1 week for the maintenance branches, but we can make exceptions. The idea was to give everyone a chance to comment. Some developers may be travelling or unavailable for other reasons. > [@dsblank](#): > > Please let us know how we can help. I’ll review the suggestions from my previous discussions on this subject. ---
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [March 16, 2026, 10:38pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/7 "2026-03-16T22:38:00Z")
I’d like to request a “polish” release to be scheduled 3 months after each major release. (delayed a bit if an emergency patch maintenance release was necessitated… since emergencies tend to absorb developer attention from less critical issues. And polish is, by definition, less critical.) Polish might include: - extra push to request translations for newly added features - UX improvements (changing default gramplet sets, tuning defaults) - import/export plug-in expansions - built-in plug-in enhancements (including consolidations) - add-on and plug-in management and management interface - icon improvements So – 60 days for development and then 30 days for validation and feedback. ---
**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\ **Post date:** [March 17, 2026, 1:09am UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/8 "2026-03-17T01:09:05Z")
Here is a proposal, which is basically what we do, but being more responsive to PRs: 1. Contributors make a PR, targeting: 1. master if it is not just a bug fix 2. latest maintenance branch if it is a bug fix 2. Reviewers have at least 3 weeks to review it 1. (I will personally have Claude review it too, so there is always at least one deep review + @Nick-Hall‘s) 3. Within a few weeks or so, it should be merged into its respective branch (master or maintenence) or rejected. 4. When there is enough contributions accumulated (or a certain amount of time has gone by) release a new version (maybe from both branches if warranted) If we can turn on Copilot, I recommend that. But I will have Claude review them in any event. This will make a huge difference in quality of feedback, and will help to create more timely releases. (I don’t know what goes into a package for each platform, but we might be able to automate some of that too). ---
**Author:** ![codefarmer](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@codefarmer](https://gramps.discourse.group/u/codefarmer)\ **Post date:** [March 17, 2026, 7:35pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/9 "2026-03-17T19:35:43Z")
I can get behind this proposal. To support item #4, can we be more intentional in tagging the `Target Version` in MantisBT? Developers who submit fixes can add a note to the defect suggesting which release it should be part of (following the current guidelines). Then we just visit the Mantis Roadmap page to see what’s pending. ---
**Author:** ![codefarmer](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@codefarmer](https://gramps.discourse.group/u/codefarmer)\ **Post date:** [March 19, 2026, 1:08am UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/10 "2026-03-19T01:08:00Z")
This discussion has focused mostly on source control, releases and policy, but given the current state of the 6.0.7 AIO, the CI build (not just AIO, but other platforms as well) should be included in the discussion. ---
**Author:** ![riskysnail](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/riskysnail/32/8445_2.png) [@riskysnail](https://gramps.discourse.group/u/riskysnail)\ **Post date:** [March 20, 2026, 3:27pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/11 "2026-03-20T15:27:02Z")
Instead of trying to rely on Claude (or any other AI) to do code reviews I’d recommend instead that you use the AI to create regression tests. Then setup the github ci jobs to run the tests on push. I think after waiting 22 years maybe we can start to knock a few things off this list… > ---
**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\ **Post date:** [March 20, 2026, 3:32pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/12 "2026-03-20T15:32:12Z")
I recommend both: tell you what is wrong, and create tests to show that it is broken. Simply creating the test is not enough for many of us (including me!) to know where to start to fix the issue. I would love to start knocking things off lists at a faster pace. I’m not going to be here in another 22 years 🙂 ---
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [March 22, 2026, 1:34pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/13 "2026-03-22T13:34:13Z")
Split this topic on March 22, 2026, 1:34pm UTC 2 posts were split to a new topic: [What elements could be removed from the Gramps core](https://gramps.discourse.group/t/what-elements-could-be-removed-from-the-gramps-core/9245) ---
**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\ **Post date:** [March 22, 2026, 11:08am UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/15 "2026-03-22T11:08:42Z")
@emyoulation can you make a separate post about possible items to remove (or move to addons) from Gramp? And if you could be specific, listing the item by their plugin name, or even pointing to code in github? These of course will be suggestions, and we can discuss. ---
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [March 22, 2026, 1:35pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/16 "2026-03-22T13:35:07Z")
Moved that posting and the 1 reply to: > [@What elements could be removed from the Gramps core](https://gramps.discourse.group/t/what-elements-could-be-removed-from-the-gramps-core/9245): > > It seems reasonable to spin out the FTREE export to be an addon and scratch that test. And CDs (or DVDs) support seem like they should be external too. Also, it seems reasonable to move 2 of the 3 navigator modes to be addons. Besides simplifying interface testing, is also narrows the navigator sidebar by eliminating the selector button. (I’d vote for reducing it to the “Drop-Down” navigator as the most GUI-efficient. People could add & switch to Category or Expander.) ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/gramps/original/1X/2ac1e712b7adf612e31ca08a55419f4cf37c0158.png) [@system](https://gramps.discourse.group/u/system)\ **Post date:** [April 21, 2026, 1:35pm UTC](https://gramps.discourse.group/t/development-process-recommendation-adopt-a-develop-integration-branch/9220/17 "2026-04-21T13:35:49Z")
Closed on April 21, 2026, 1:35pm UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.