Document the change from `MP_DATA_FILE` to `MP_DATABASE`

[RafaelKr]

My mailpit version is 1.15.1 and MP_DATABASE was only added with https://github.com/axllent/mailpit/releases/tag/v1.16.0

I just lost a bunch of mails because I used MP_DATABASE which I got from here: https://mailpit.axllent.org/docs/configuration/runtime-options/

I would suggest to add a note to the documentation that MP_DATABASE is only available since v1.16.0.

[axllent]

Point noted, however using that logic I would need to document the same for every flag / option which doesn't make sense. Can you please tell me why you are using a much older version of Mailpit?

[RafaelKr]

Symfony has a nice way of documenting features that were added with a specific version.

Some examples: https://symfony.com/doc/current/mailer.html#disabling-automatic-tls https://symfony.com/doc/current/components/filesystem.html#readfile

Can you please tell me why you are using a much older version of Mailpit?

Unfortunately it's currently the latest version available for NixOS. For both, the stable channel 24.05 and the unstable channel aswell: https://search.nixos.org/packages?channel=24.05&from=0&size=50&sort=relevance&type=packages&query=mailpit

For many packages a bot can create update PRs to nixpkgs. Maybe the bot couldn't automatically resolve the new dependencies for the update from 1.15.1 => 1.16.0 and nobody did it manually yet. https://github.com/NixOS/nixpkgs/blob/c5bcace2113d93a989966b4bd2dc1b3d957a0c61/pkgs/servers/mail/mailpit/default.nix

[RafaelKr]

I just created a PR at nixpkgs to update mailpit to the latest version. https://github.com/NixOS/nixpkgs/pull/323881

[axllent]

Again, I do apologise that you lost emails as a result of using an outdated version of Mailpit with current documentation, though these things should always be tested before being put into production. Unlike flags, unsupported environment variables do not generate errors in any application.

I do carefully deprecate flags though, meaning if users are using flags or environment variables that are no longer relevant, renamed or removed, then a deprecation warning is typically shown for at least a year after the deprecation. This does not address the situation of using an old version of Mailpit with newer documentation though. I have updated the runtime options page to add versions next to some of the more recent options, so hopefully this helps prevent this issue in future. Thanks for the advise.

Also thanks for the PR to Nix :+1: I haven't a clue who maintains that, or why it's not up-to-date. I do know that FreeBSD update usually within an hour or two of new releases, so this is automated on their end.

[RafaelKr]

It wasn't too bad, it was only running for a day in a Staging environment, then my systemd Service was restarted and the mails were gone. Took me quite a while to figure out that it was due to the not-yet-existing MP_DATABASE env var. Your addition to the docs can definitely help with that, thank you very much!

It can be even improved a little further by linking to the Release Page on GitHub. You write very good release notes, with that someone can follow pretty good what changed, e.g. MP_DATA_FILE to MP_DATABASE. In fact I did set both variables now, so as soon as my PR is released into unstable I can easily update to v1.19.0.

Usually the update process for nixpkgs is automated for a lot of packages via nixpkgs-update, based on the information from https://repology.org/ The bot also did the last PR from 1.15.0 to 1.15.1: https://github.com/NixOS/nixpkgs/pull/301724

But nix always requires that a hash of the build output is provided, this ensures reproducability. It seems like the bot is not able to do the automatic update when also the npm dependencies (and thus their hash) changed.

I subscribed to mailpit release notifications now. When I have the time I will keep the nixpkgs mailpit version up to date.

[RafaelKr]

@axllent I just found it's possible to declare how packages can be updated by providing the passthru.updateScript attribute.

If I have time I'll investigate how I can make this work so mailpit is also automatically updated in the nix package repository. https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#automatic-package-updates

[axllent]

@RafaelKr That's awesome, I did not know about https://repology.org/. I can see how the node build requirement part can complicate things a bit though.

[axllent]

Just a note about linking to the release page for each of those versions - whilst nice, I'd rather not because I then run the risk of unsuspecting users inadvertently downloading old releases because they "got the link from the website" ;-) I could link them to the CHANGELOG, but it's not always a nice summary like on the release pages (I sometimes put additional info in the releases).

[RafaelKr]

I just implemented the passthru.updateScript for mailpit in nixpkgs, so their bot can automatically create update PRs :tada: https://github.com/NixOS/nixpkgs/pull/324026

Now it also doesn't depend on repology anymore, the latest version information is directly fetched from the GitHub API.

[RafaelKr]

Just a note about linking to the release page for each of those versions - whilst nice, I'd rather not because I then run the risk of unsuspecting users inadvertently downloading old releases because they "got the link from the website" ;-) I could link them to the CHANGELOG, but it's not always a nice summary like on the release pages (I sometimes put additional info in the releases).

@axllent Okay fine, I get that point. Then this case is closed, thanks!