Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/stalwart-mail: add module-local stateVersion option #321873

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pacien
Copy link
Contributor

@pacien pacien commented Jun 23, 2024

Description of changes

This adds a services.stalwart-mail.stateVersion option allowing the
consumer to choose which defaults to use for this module. This is
desirable for those wishing to use the new defaults before the next
release, and eases state migration for just this module.

This follows the discussion at
#315908 (comment)

CC: @Shawn8901

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

This adds a `services.stalwart-mail.stateVersion` option allowing the
consumer to choose which defaults to use for this module. This is
desirable for those wishing to use the new defaults before the next
release, and eases state migration for just this module.

This follows the discussion at
NixOS#315908 (comment)
@Shawn8901
Copy link
Contributor

After longer thinking about your response on my suggestion is agree with you that we should not add a local state version.

The main problem on the old code on my opinion was, that is was a very bad UX in override to state logic and bootstrapping logic of the state dir (which is still a topic on my opinion when someone wants to move that), let's improve on that UX and try to avoid additional states. Choosing defaults based on the nixos State version is the right approach, and adding more state is possibly not the best idea I had :)

Let me think some days over how I would try to increase that UX without adding more state Version and not over complicating the modules logic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants