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.
PRs target develop immediately — they get merged, tested, and can build on each other.
When a major release is ready, cut a maintenance/gramps61 branch from develop, tag a release, and merge to master.
Bug fixes go to the relevant maintenance/ branch and are cherry-picked back to develop.
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.
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.
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.
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!
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.
Yes, please! Is Copilot Review enabled in gramps and addons-source review? It is enabled in the gramps-web-api repo.
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.
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.
I’ll review the suggestions from my previous discussions on this subject.
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
Here is a proposal, which is basically what we do, but being more responsive to PRs:
Contributors make a PR, targeting:
master if it is not just a bug fix
latest maintenance branch if it is a bug fix
Reviewers have at least 3 weeks to review it
(I will personally have Claude review it too, so there is always at least one deep review + @Nick-Hall‘s)
Within a few weeks or so, it should be merged into its respective branch (master or maintenence) or rejected.
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).
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.
