# Gramps 6.1 Planning **URL:** \ **Category:** Development\ **Created:** [March 23, 2026, 10:40am UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249 "2026-03-23T10:40:08Z")\ **Posts on this page:** 20\ **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 23, 2026, 10:40am UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/1 "2026-03-23T10:40:08Z")
# Gramps v6.1 non-draft Open PRs There are currently 42 open non-draft PRs (Pull Requests). These would make the foundation of Gramps 6.1. I’ve broken them down into 3 groups: 1. Those that should be reviewed+merged first either to cut down on merge conflicts, or to allow additional PRs and development (gramps desktop and web) 2. Regular bug fixes and enhancements 3. Items that should be merged at the end of the 6.1 development process I suggest we review and merge the PRs in this order. If you are working on something (draft or otherwise) please leave a message on this post. If you have a suggestion for changing the order, let me know and I will edit this list. Group 1: | # | Title | Author | +/- | Review | | --- | --- | --- | --- | --- | | [#2195](https://github.com/gramps-project/gramps/pull/2195) | Refactor proxy system: two-layer include/sanitize filtering | dsblank | +1173/-2059 | — | | [#1934](https://github.com/gramps-project/gramps/pull/1934) | Minimal code changes to support type hinting of db methods | stevenyoungs | +323/-178 | — | | [#2184](https://github.com/gramps-project/gramps/pull/2184) | Add type hints to gen/lib classes and fix filter rule type errors | dsblank | +370/-52 | — | | [#2128](https://github.com/gramps-project/gramps/pull/2128) | Protocols for typing of Gramps objects | DavidMStraub | +645/-1 | — | | [#2178](https://github.com/gramps-project/gramps/pull/2178) | Add JSON field indexes on json\_data handles | dsblank | +52/-0 | — | | [#2180](https://github.com/gramps-project/gramps/pull/2180) | Live filter UI updates, responsiveness, and O(n²) fix | dsblank | +100/-21 | — | | [#2162](https://github.com/gramps-project/gramps/pull/2162) | Add config to allow ignore XML mediapath | dsblank | +4/-1 | — | | [#2160](https://github.com/gramps-project/gramps/pull/2160) | Optimizer: skip loop when all rules are optimized | dsblank | +81/-40 | — | Independent bug fixes and/or enhancements: | # | Title | Author | +/- | Review | | --- | --- | --- | --- | --- | | [#2182](https://github.com/gramps-project/gramps/pull/2182) | sort\_key: replace hexlify with getSortKey() bytes, drop binascii import | dsblank | +243/-6 | — | | [#2181](https://github.com/gramps-project/gramps/pull/2181) | edit INSTALL | ClmntPnd | +9/-2 | — | | [#2177](https://github.com/gramps-project/gramps/pull/2177) | Add register\_override API so DB backends can use optimized implementations | dsblank | +289/-1 | — | | [#2176](https://github.com/gramps-project/gramps/pull/2176) | FamilySearch Integration | SourceAirbender | +18353/-7 | Changes requested | | [#2165](https://github.com/gramps-project/gramps/pull/2165) | Save filter dates in locale-independent format | dsblank | +44/-3 | — | | [#2164](https://github.com/gramps-project/gramps/pull/2164) | Better default Tag colors | dsblank | +82/-4 | — | | [#2161](https://github.com/gramps-project/gramps/pull/2161) | Add order change UI for rules in filter editor | dsblank | +247/-4 | — | | [#2154](https://github.com/gramps-project/gramps/pull/2154) | Improved Manage Family Trees behavior when deleting trees: preserve sort column and better next item selection | hgohel | +45/-2 | Changes requested | | [#2153](https://github.com/gramps-project/gramps/pull/2153) | Use filter.apply() rather than apply\_to\_one() | dsblank | +217/-222 | — | | [#2150](https://github.com/gramps-project/gramps/pull/2150) | Add tearDownClass method to cleanup after unit test | hgohel | +9/-0 | — | | [#2149](https://github.com/gramps-project/gramps/pull/2149) | fix: add resilience to set\_birth\_death\_index() for storage backend failures | mahula | +47/-13 | Changes requested | | [#2142](https://github.com/gramps-project/gramps/pull/2142) | subdirs and comments in narweb css files | SNoiraud | +20/-4 | Changes requested | | [#2132](https://github.com/gramps-project/gramps/pull/2132) | Avoid opening a Citation when dragging or selecting an existing one | roptat | +2/-38 | — | | [#2131](https://github.com/gramps-project/gramps/pull/2131) | birth/death estimation improvement | Rak424 | +43/-1 | — | | [#2111](https://github.com/gramps-project/gramps/pull/2111) | Graph algorithms | dsblank | +949/-300 | — | | [#2100](https://github.com/gramps-project/gramps/pull/2100) | NarrativeWeb: Add non-sharable notes to media | SNoiraud | +161/-18 | — | | [#2091](https://github.com/gramps-project/gramps/pull/2091) | Add a favorites sidebar and all persistent sidebar | SNoiraud | +377/-0 | — | | [#2084](https://github.com/gramps-project/gramps/pull/2084) | Internet indexing for the Narrative Web | SNoiraud | +11/-2 | — | | [#2083](https://github.com/gramps-project/gramps/pull/2083) | Pass an object rather than a handle to the note editor callback #2 | stevenyoungs | +28/-21 | — | | [#2050](https://github.com/gramps-project/gramps/pull/2050) | Fix icu/PyICU exception handling in narrated web report | martin-schwenke | +8/-8 | — | | [#2037](https://github.com/gramps-project/gramps/pull/2037) | Add a HasNoteTag filter rule | stevenyoungs | +466/-0 | — | | [#2036](https://github.com/gramps-project/gramps/pull/2036) | Add HasNoteType filter rules for Media and Repository objects | stevenyoungs | +96/-0 | — | | [#2010](https://github.com/gramps-project/gramps/pull/2010) | Fix IsMoreThanNthGenerationDescendantOf.init\_list() typing | stevenyoungs | +3/-5 | — | | [#2005](https://github.com/gramps-project/gramps/pull/2005) | Add a “References” tab to the editfamily dialog | stevenyoungs | +57/-0 | — | | [#2001](https://github.com/gramps-project/gramps/pull/2001) | New calendar | SNoiraud | +318/-5 | — | | [#1998](https://github.com/gramps-project/gramps/pull/1998) | Allow invalid dates in the relationship graph | SNoiraud | +12/-2 | — | | [#1988](https://github.com/gramps-project/gramps/pull/1988) | Fix man page updates | Nick-Hall | +10/-10 | — | | [#1979](https://github.com/gramps-project/gramps/pull/1979) | Use https instead of http | stevenyoungs | +269/-269 | — | | [#1963](https://github.com/gramps-project/gramps/pull/1963) | Allow filters to be cancelled | dsblank | +291/-172 | — | | [#1919](https://github.com/gramps-project/gramps/pull/1919) | Add type hints to db classes | stevenyoungs | +1530/-919 | — | | [#1882](https://github.com/gramps-project/gramps/pull/1882) | Refactor Relationship Calculator and Add a Searchbar | stevenyoungs | +208/-282 | Changes requested | | [#1873](https://github.com/gramps-project/gramps/pull/1873) | Improved Descendant Tree and Ancestor Tree new features | dave-khuon | +166/-6 | — | | [#699](https://github.com/gramps-project/gramps/pull/699) | FR10850 V2: freeze/unfreeze button per gramplet | SNoiraud | +70/-16 | — | We probably want to save these until the end, as they will cause version 21 databases to be unavailable in master without upgrade: | # | Title | Author | +/- | Review | | --- | --- | --- | --- | --- | | [#2141](https://github.com/gramps-project/gramps/pull/2141) | Version 22: Coalesce event role types | stevenyoungs | +62/-2 | Changes requested | ---
**Author:** ![csam](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/csam/32/5361_2.png) [@csam](https://gramps.discourse.group/u/csam)\ **Post date:** [March 23, 2026, 12:51pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/2 "2026-03-23T12:51:05Z")
Thank you very much. Even for a non-developer it is interesting to see what to expect for new releases. But it also raises some questions. What about all the feature requests in the Gramps Bugtracker (MantisBT). Is there any formal prioritisation rules, for a feature request to be considered for the next release? Users often asks for a new feature or improved UI in the Gramps Discourse categories ‘Ideas’ or ‘Help’. Is such requests considered or are they ignored until there is a feature request in the Bugtracker or a Pull Request in Git? Is there any means to raise attention for a particular request, or could/should we have a voting for which feature requests to prioritise for the next release? TIA Claus ---
**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 23, 2026, 1:03pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/3 "2026-03-23T13:03:06Z")
> [@csam](#): > > What about all the feature requests in the Gramps Bugtracker (MantisBT). Is there any formal prioritisation rules, for a feature request to be considered for the next release? Not as far as I am aware. I guess developers work on whatever they are interested in. > [@csam](#): > > Users often asks for a new feature or improved UI in the Gramps Discourse categories ‘Ideas’ or ‘Help’. Is such requests considered or are they ignored until there is a feature request in the Bugtracker or a Pull Request in Git? The PRs in git are of course made by developers. So if their contribution is seen as good, it is generally accepted. Regarding other feature requests… > [@csam](#): > > Is there any means to raise attention for a particular request, or could/should we have a voting for which feature requests to prioritise for the next release? It would be wonderful if the users could self-organize a list of priorities that they would like to see added to the next version. I, for one, would be glad to work down a list of prioritized features for inclusion! ---
**Author:** ![GeorgeWilmes](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@GeorgeWilmes](https://gramps.discourse.group/u/GeorgeWilmes)\ **Post date:** [March 23, 2026, 3:34pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/4 "2026-03-23T15:34:06Z")
> [@dsblank](#): > > It would be wonderful if the users could self-organize a list of priorities that they would like to see added to the next version. I think it might help if developers could identify, and discuss the implications of, technical changes that need to happen in next few years. For example, “we should move from GTK3 to GTK4 (or whatever) by x date, and doing so will give us the ability do these new things, and make it easier to improve these old things”. Maybe AI can also help analyze the backlog. Many requests are already marked as “related” but it might identify more connections. Then, developer input could again be helpful, for example “each of the issues in this group would individually be a pain in the neck and not worth my time, but if we changed how the such-and-such worked, then it would be straightforward to implement them.” Or another example, “the requests in this group are probably not useful to many people besides the requestors, but if we changed x, then users could tweak things to their desire.” > [@dsblank](#): > > I, for one, would be glad to work down a list of prioritized features for inclusion! Thank you! ---
**Author:** ![codefarmer](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@codefarmer](https://gramps.discourse.group/u/codefarmer)\ **Post date:** [March 23, 2026, 5:50pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/5 "2026-03-23T17:50:02Z")
@Nick-Hall @dsblank @SteveY and other Gramps developers: When a PR introduces a breaking API change that may end up breaking 3P addons, what should be done to ensure minimum disruption? Case in point, for [PR #2083](https://github.com/gramps-project/gramps/pull/2083) there are comments indicating such a breaking change and that the PR should be targeted to Gramps 6.1. Should the author of the PR add a commit in the same PR to fix the addons so that the build remains stable? ---
**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 23, 2026, 6:00pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/6 "2026-03-23T18:00:36Z")
> [@codefarmer](#): > > Should the author of the PR add a commit in the same PR to fix the addons so that the build remains stable? Our goal for Gramps 6.1 is that we will have proper checks not only for the correct number of arguments that are passed into functions, but that they will also be checked to be of the correct type. My suggestion would be to add that requirement to the 3rd party addons for 6.1 (using mytype) so that it will automatically catch and prevent any such addon from being accepted. It will be the addon’s author’s responsibility to either fix any breaking change, or their addon just won’t be accepted. (In technical terms, an addon commit can’t be in the same PR as that is a different repository, but I get your meaning.) ---
**Author:** ![GaryGriffin](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/garygriffin/32/6525_2.png) [@GaryGriffin](https://gramps.discourse.group/u/GaryGriffin)\ **Post date:** [March 23, 2026, 7:01pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/7 "2026-03-23T19:01:21Z")
> [@codefarmer](#): > > Should the author of the PR add a commit in the same PR to fix the addons so that the build remains stable? I have to disagree. If the core developer breaks an API, I think it is upon them to fix both any occurrence in core as well as addons. I could imagine one core PR for the commit and to cover core breakage. And an Addon PR to cover all breakage there. The Addon PR could be part of the migration path when a new release is created. ---
**Author:** ![codefarmer](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@codefarmer](https://gramps.discourse.group/u/codefarmer)\ **Post date:** [March 23, 2026, 7:06pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/8 "2026-03-23T19:06:15Z")
I believe we agree that the author of the core PR should ensure that the addons work. I wasn’t thinking that because addons-source is a separate repo, it has to be two separate PRs as Doug reminded me 🙂 ---
**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 23, 2026, 7:07pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/9 "2026-03-23T19:07:56Z")
> [@GaryGriffin](#): > > If the core developer breaks an API Actually, in this particular case the developer is fixing an API in a proper way. I think it is asking a core developer to do too much to figure out what a 3rd party addon should do. I think it is perfectly reasonable to ask an addon contributor to maintain their own work. ---
**Author:** ![StoltHD](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@StoltHD](https://gramps.discourse.group/u/StoltHD)\ **Post date:** [March 23, 2026, 8:00pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/10 "2026-03-23T20:00:44Z")
> [@dsblank](#): > > It would be wonderful if the users could self-organize a list of priorities that they would like to see added to the next version. > > I, for one, would be glad to work down a list of prioritized features for inclusion! We had a long discussion about features when Nick posted the Roadmap for 5.3/6.0… > [@Roadmap for v5.3 (correction: 6.0)](https://gramps.discourse.group/t/roadmap-for-v5-3-correction-6-0/5203/): > > Now that the release of v5.2 is behind us, it is time to think about the roadmap for the next major release. I’ve already posted to the gramps-devel mailing list, but user feedback is also important to us. Firstly, I’d like to say that the time it took us to release v5.2 was far too long. At the start Covid was a factor, and then the amount of work required became large which was rather daunting. We must make an effort to release Gramps more frequently, and I have indicated that I am willing… At least the first half of it is about features wanted… I will again mention my 3x two cents. 1. Main-/Sub Events 2. Events on Places 3. CSL support and a hierarchical and extended feature for Repositories/Sources/Citations (RSC)… In addition, I do not know how much more all of you devs work with moving logic from the frontend to the backend for speed, but I think that is something most users with larger databases still need more of… (speed)… * * * Ooh, one more thing… Regarding time periods: please move away from the GEDCOM logic ASAP… * * * **But as a whole:** My earlier posts in the roadmap thread outline the structural backend changes needed for long‑term performance — JSON‑based storage, proper indexing, database views, and multi‑threading support. In addition, I’ve already described 3–4 core features that would lift Gramps several floors in the **humaniora‑oriented research field**. **These are still my priorities.** ---
**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 23, 2026, 8:33pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/11 "2026-03-23T20:33:17Z")
> [@dsblank](#): > > I think it is asking a core developer to do too much to figure out what a 3rd party addon should do. > > I think it is perfectly reasonable to ask an addon contributor to maintain their own work. Our current policy is that core developers to not have to update third-party addons after an API change. However, in the past, some developers have updated addons as a courtesy. ---
**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 23, 2026, 8:50pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/12 "2026-03-23T20:50:28Z")
Also, not very often do we create things that need to be fixed that the addons use. But using the mypy and other tools will make this easy to find problems, which we have never used before, and have created issues. ---
**Author:** ![SteveY](https://avatars.discourse-cdn.com/v4/letter/s/85e7bf/32.png) [@SteveY](https://gramps.discourse.group/u/SteveY)\ **Post date:** [March 23, 2026, 10:34pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/13 "2026-03-23T22:34:14Z")
In this case, as the PR author, I don’t believe that it will be easy to identify which, if any, add-ons are broken by the change. You would need to identify the expected type of an argument to a callback function in the add-on. The breaking change was necessary to fix core gramps which is broken in 6.0 and earlier versions. ---
**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 27, 2026, 1:04pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/14 "2026-03-27T13:04:30Z")
@Nick-Hall it seems like the bug fixes that are applied to a maintenance branch are not immediately applied to master. This makes it difficult to work on master. Is there any reason not to immediately apply a maintenance fix to master? ---
**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 27, 2026, 4:49pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/15 "2026-03-27T16:49:52Z")
The maintenance branches are merged into the _master_ branch on a regular basis. The last branch merge was on 20th March and there haven’t been any bug fixes committed since then - just some translations and changes to the AIO build. I can merge at any time when there is a reason to do so. ---
**Author:** ![SteveY](https://avatars.discourse-cdn.com/v4/letter/s/85e7bf/32.png) [@SteveY](https://gramps.discourse.group/u/SteveY)\ **Post date:** [March 29, 2026, 10:53am UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/16 "2026-03-29T10:53:28Z")
@Nick-Hall it would be helpful to me if the AIO fixes in gramps60 can be merged into master sooner rather than later. ---
**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 29, 2026, 1:58pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/17 "2026-03-29T13:58:40Z")
I’ve just merged the _gramps60_ branch into _master_ again. ---
**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:** [April 1, 2026, 7:50pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/18 "2026-04-01T19:50:40Z")
@Nick-Hall What is your plan for starting to merge the 6.1 PRs into master? There are going to be lots of merge conflicts as we go, and I for one could start working on a 6.1 addon once we start getting the above merged. ---
**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:** [April 1, 2026, 8:38pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/19 "2026-04-01T20:38:51Z")
> [@dsblank](#): > > What is your plan for starting to merge the 6.1 PRs into master? I usually do this in two passes. Firstly, I merge the small PRs that are easy to review and test. They also are less likely to have conflicts. I have started this process already. Then I review the larger PRs and decide what will go into the next release. This obviously takes longer. I leave merging the large PRs until shortly before creation of the new maintenance branch. In the past I have had problems merging the maintenance branch if this is done too early. After this I create the new maintenance branch, a new addons branch and point Weblate at the new branches. This will be about three months before the planned release date to give the translators a good amount of time. The current roadmap was to plan for the next feature release around 1 Oct 2026. However, I am still in discussions with FamilySearch and our plans may change. ---
**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:** [April 2, 2026, 2:58pm UTC](https://gramps.discourse.group/t/gramps-6-1-planning/9249/20 "2026-04-02T14:58:48Z")
> [@Nick-Hall](#): > > The current roadmap was to plan for the next feature release around 1 Oct 2026. However, I am still in discussions with FamilySearch and our plans may change. To be released earlier than Oct, or later? What are these discussions like? Do they involve developers from our side? I’m the only one so far that has started reviewing the 19k lines of code, and don’t really know what the goals or timeframe is. Feel free to invite me to any FS conversation. I’m also worried that some of the speed improvement PRs might not get in because of the focus on FamilySearch. Can you add some transparency to the FS conversation? [Next page](https://gramps.discourse.group/t/gramps-6-1-planning/9249.md?page=2)