Geary packagers and hackers! We're considering requiring a build profile to be required for `meson setup` to succeed, can we get your input on this change?
https://discourse.gnome.org/t/rfc-requiring-a-profile-to-be-specified-when-building-geary/4405
Thanks! 🙏
@geary Please, don't. Is it possible just to create versioned DB for each schema version and then execute migration script which will find latest previous one and copy the data over?
@ruff Hey, thanks for the comment, but it would be more useful to know why you would rather this doesn't go ahead instead of suggestions for alternatives.
@geary to me it looks counter-intuitive to provide options to do _something_. Usually options are required to do _something specific_ which is different from mere _something_
@ruff yes, agreed. As mentioned in the post defaulting to the development profile would be preferred, but packagers might not pick up on it and ship a development build.
One alternative might be to default to development for now, switch to requiring it to be explicitly set when approaching the release for 40, then switch back to development as the default again after that is out.
@geary well, ok if choosing dev profile is undesirable for general public then shouldn't it default to stable, and then when someone needs _something specific_ like a dev profile, they provide options?
@ruff The general public should be downloading releases (and betas) as pre-compiled packages from their distro or from Flathub, and these must obviously be built with the appropriate profile.
Building from source is primarily a development-oriented activity, and so it makes most sense to not default to the release profile in the source repo.
This leaves the question: Should we ask if not specified, or should we just assume the development profile? Hence the RFC. :)
@geary I meant packagers (or rather packaging scripts) for general public. If they are not providing build profile in majority - would still make sense to default to stable and drop a line in INSTALL about development to likely prefer development profile instead of default stable. So from developer perspective I'm fine to explicitly ask for bleeding edge and build package-like release otherwise.
@geary well then I don't quite understand the problem statement in the OP. To me it looks consistent and right - by default continuity is maintained, if someone wants to jump ahead - he should explicitly ask for that.
@ruff I'm not sure what you mean by jump ahead - as in build a development version from source?
If so then someone who does so is likely wanting to test a bug or contribute to Geary, and hence by checking out the source and building it they have already explicitly chosen to build a development version.
@ruff Requiring they then have to realise and then go looking for yet another thing to do in between checkout and build (which happens at the same time in modern toolchains) just to get the right behaviour is just putting up an additional, unnecessary roadblock. One that also has a bad side-effect: Possible irreversible upgrades of their day-to-day account databases.
Can I ask, are you coming to this from the perspective of a maintainer or someone who builds Geary from source for other reasons?
@geary someone who builds from source when need to test various features not in the packaged build. So my build will always be specific. but my expectations normally is if i don't provide any options (only defaults) I'd get so called vanilla build.
@ruff Right, so you're exactly the who we're trying to avoid clobbering your day-to-day database by doing this.
The trade off here for you is either (a) get a very slightly different build by default when building from source vs (b) having to delete your email databases for each account and re-download all of your email for them whenever you run a version that contains a database upgrade and you want to go back to a release version afterwards.
@ruff Note that there would literally no functional difference between a development and release build other than a) changes to branding to denote a development build an b) data is stored in a different location.
@ruff That's the status quo, and hence exhibits the problem in the post that we're trying to avoid. :)