I’m considering making it mandatory to specify a build profile (one of release, development, or beta) when configuring a Geary build using meson. That is, people would have to do at a minimum meson -Dprofile=development build for build config to succeed.
Would this be terribly onerous for packagers and people using tools like GNOME Builder?
The rationale is that since Geary uses a SQL database for local storage, and since we need to sometimes migrate the schema in backwards incompatible ways, keying storage location off the build profile allows Geary to keep separate release/beta/dev databases, letting people test out development branches that may contain db migrations but still go back to running release versions.
I’d consider changing the default build profile to development rather than release, but packagers may miss the change and end up shipping development builds rather than release ones.
Another option would be to default to the development profile if there is a directory named .git present, else require it be specified.
This would mean that people building from source to test a bug fix won’t get their day-to-day database upgraded and people using (say) Builder wouldn’t get build failures until working out how to set the profile, but when distributions build from a tarball they must specify the profile.
Maybe don’t default to anything and error if no profile is selected, saying something like “If you’re a packager, then add -Dprofile=release” or something like that ? Then in the development flatpak manifest you could add the “development” profile (and the “release” one for flathub’s one).
In Boxes we have a similar issue with the virtual machine storage not being backwards compatible with some changes.
What we do is that we change the application-id when setting the “devel” profile, so the development version of the app has a different name on its desktop file, different icon, the “devel” style class in its headerbar, etc… A packager ~that actually tests~ your application would easily understand that there’s something different about the app.
I guess that’s what I was hoping to get feedback from packagers from - whether they would likely pick it up without having to put an explicit check in.
Well: If you want someone to notice a change: make it break when it builds. Meaning: it should not build anymore. But I don’t actually see the need here. You can detect the existence of a .git directory, various projects already do that. Same for the devel case, I do not see why a packager would need to say it’s a development version. The maintainer would know by setting the version correctly.
I have a script which runs off ftp-release-list which automates the most common things away. So checking if it is ok to update to that version, actually changing the .spec, checking if patches still apply, waiting for other dependencies to build, etc. I often do not look at any changes beforehand. Sometimes after the fact. So it not building is helpful. That happens more often with new dependencies (didn’t automate that yet), or e.g. people switching to meson.
