[GH-ISSUE #328] Document the change from `MP_DATA_FILE` to `MP_DATABASE`

kerem commented

2026-03-15 13:15:32 +03:00

Owner

Originally created by @RafaelKr on GitHub (Jul 1, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/328

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.

Originally created by @RafaelKr on GitHub (Jul 1, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/328 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`.

kerem closed this issue

2026-03-15 13:15:37 +03:00

kerem commented

2026-03-15 13:15:43 +03:00

Author

Owner

@axllent commented on GitHub (Jul 1, 2024):

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?

@axllent commented on GitHub (Jul 1, 2024): 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?

kerem commented

2026-03-15 13:15:48 +03:00

Author

Owner

@RafaelKr commented on GitHub (Jul 1, 2024):

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.
github.com/NixOS/nixpkgs@c5bcace211/pkgs/servers/mail/mailpit/default.nix

@RafaelKr commented on GitHub (Jul 1, 2024): 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

kerem commented

2026-03-15 13:15:53 +03:00

Author

Owner

@RafaelKr commented on GitHub (Jul 1, 2024):

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

@RafaelKr commented on GitHub (Jul 1, 2024): I just created a PR at nixpkgs to update mailpit to the latest version. https://github.com/NixOS/nixpkgs/pull/323881

kerem commented

2026-03-15 13:15:58 +03:00

Author

Owner

@axllent commented on GitHub (Jul 2, 2024):

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 👍 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.

@axllent commented on GitHub (Jul 2, 2024): 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](https://mailpit.axllent.org/docs/configuration/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.

kerem commented

2026-03-15 13:16:04 +03:00

Author

Owner

@RafaelKr commented on GitHub (Jul 2, 2024):

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 commented on GitHub (Jul 2, 2024): 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](https://nix-community.github.io/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.

kerem commented

2026-03-15 13:16:09 +03:00

Author

Owner

@RafaelKr commented on GitHub (Jul 2, 2024):

@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

@RafaelKr commented on GitHub (Jul 2, 2024): @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

kerem commented

2026-03-15 13:16:14 +03:00

Author

Owner

@axllent commented on GitHub (Jul 2, 2024):

@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 commented on GitHub (Jul 2, 2024): @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.

kerem commented

2026-03-15 13:16:19 +03:00

Author

Owner

@axllent commented on GitHub (Jul 2, 2024):

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 commented on GitHub (Jul 2, 2024): 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).

kerem commented

2026-03-15 13:16:24 +03:00

Author

Owner

@RafaelKr commented on GitHub (Jul 2, 2024):

I just implemented the passthru.updateScript for mailpit in nixpkgs, so their bot can automatically create update PRs 🎉
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 commented on GitHub (Jul 2, 2024): 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.

kerem commented

2026-03-15 13:16:29 +03:00

Author

Owner

@RafaelKr commented on GitHub (Jul 2, 2024):

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!

@RafaelKr commented on GitHub (Jul 2, 2024): > 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!

kerem referenced this issue

2026-03-15 14:21:15 +03:00

[PR #215] [MERGED] Add @ as valid character for webroot #479

Rows
Columns

[GH-ISSUE #328] Document the change from MP_DATA_FILE to MP_DATABASE #215

[GH-ISSUE #328] Document the change from `MP_DATA_FILE` to `MP_DATABASE` #215