@DavidMStraub announced the 3.0 Gramps Web API (the 1st Gramps 6.0 compatible version) on 4 May 2025 and, shortly after that, the v25.5.0 of the Gramps Web frontend.
These announcements don’t get into the “News” or “Releases” announcement channels that feed the RSS Headline News Gramplet.
And the visibility of current Gramps Web version numbers are not prominent on the wiki. (I added links to the GitHub Releases pages for the frontend and backend to the wiki’s download page… the MediaWiki version, not the WordPress download page where Gramps Web is not mentioned. Nor are there any download links the Gramps Web features page on the WordPress pages, just demo and docs pages.)
I do not know how many Gramps Web installations exist compared to Gramps for desktops. But it seems to be gaining an audience. So should visibility should be stepped up in the Announcements section here on Discourse and the rest of the communication channels?
An “Announcing the new release” workflow was developed over the years for Gramps for desktops. Does David need a similar workflow (and rights to the various systems) to do major release announcements for Gramps Web? (There are frequent asyncronous incremental releases of the frontend and backend. So maybe the Announcement workflow should be for major releases?)
1 Like
Good points.
I think posting in the “announcements” channel in discourse would make sense (I currently don’t have permission though).
If a “previous versions” table in the Wiki would be useful, I could create one.
Concerning versioning:
- Gramps Web API uses semantic versioning MAJOR.MINOR.PATCH
- The frontend uses calendar versioning YY.MM.MICRO
Usually, I release a new frontend version soon after the new Web API version so the docker images contain both new components. I could then bundle the announcements (which would also be an added benefit to the Github release pages, which are obviously separate).
1 Like
I was oblivious to the versioning being related to the calendar. That makes it easier to follow. Thanks.
However, the format apparently uses “YY.M.MICRO” rather than the leading zero “YY.MM.MICRO” variant. Leading Zeroes would alphabetically auto-sort more cleanly.
Should MICRO be a 3‐digit leading zero format? So a YY.MM.nnn format?
I should have linked CalVer: MM is not zero padded, 0M would be, but I decided against it as this makes the version technically a valid SemVer.
Naive alphabetic sorting of version numbers is not something that should be expected to work, ever, IMO. "3.10" sorts before "3.9".
No, I don’t think it should, as it is completely analogous to PATCH in SemVer.
1 Like
By the way, I did some research - clearly, the numbers are going up based on feedback (issues, PRs) and Github stars (now close to 750, while webtrees just reached 600). Looking at Github container registry download counts and Github stars, ChatGPT thinks that the number of active, docker-based installations is probably around 7,000 to 15,000.
1 Like
Interesting for comparison: https://dev.webtrees.net/statistics.html
It looks like webtrees has telemetry (anonymized, sending a UUID and version info) that can not be opted out from.
1 Like
I’ve always felt that polling the plugin addons- xx .json should collect some data. It probably would not find all the installations (since not everyone checks for updates and some may be firewalled) but would be a good sampling of active installations. (I believe that Gramps may try to poll the addons list on startup. So that might also be a “no opt out”.)