[GH-ISSUE #191] releases too frequent #125

New issue

Closed

opened 2026-03-15 12:44:53 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 12:44:53 +03:00

Owner

Originally created by @apreiml on GitHub (Oct 16, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/191

Hi,

i'm maintainig mailpit in the AUR: https://aur.archlinux.org/packages/mailpit

I'm trying to keep the package up to date, but it's too much if there are releases every few days.

So I'm asking for less frequent releases. I'd like to suggest to patch smaller changes together into bigger releases and maybe only release, if there's notable bug fixes or additional features.

Originally created by @apreiml on GitHub (Oct 16, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/191 Hi, i'm maintainig mailpit in the AUR: https://aur.archlinux.org/packages/mailpit I'm trying to keep the package up to date, but it's too much if there are releases every few days. So I'm asking for less frequent releases. I'd like to suggest to patch smaller changes together into bigger releases and maybe only release, if there's notable bug fixes or additional features.

kerem closed this issue

2026-03-15 12:44:58 +03:00

kerem commented

2026-03-15 12:45:05 +03:00

Author

Owner

@axllent commented on GitHub (Oct 16, 2023):

Hi @apreiml. Firstly I should say thank you for maintaining the Arch Linux package for Mailpit - it's nice to see it's popularity growing and adoption into mainstream platforms.

It is an interesting point you raise. On the one hand I get it - if you are having to manually make changes every time then I see how this can be frustrating. What is actually involved on your end when there is a new release? I note that FreeBSD appears to also have a Mailpit package which (from what I can tell) is automated, or at least mostly automated, and their releases usually come within hours of a Mailpit release.

maybe only release if there's notable bug fixes or additional features

To be honest, this is mostly how it currently works. The release I just did includes some necessary swagger fixes to allow someone else to build their API tooling, plus a security fix and a few module updates. The release before that a bugfix, and before that inline message previews etc. Basically almost every release adds new features, and they aren't just releases for the sake of it.

Could the number of releases be reduced? Quite possibly. What do you believe is a reasonable release cycle for a fast-paced (so far anyway) open source project, and if it is too fast for you to maintain, is there any reason you have to build an AUR package for every release (could you not just slow down your end)?

@axllent commented on GitHub (Oct 16, 2023): Hi @apreiml. Firstly I should say thank you for maintaining the Arch Linux package for Mailpit - it's nice to see it's popularity growing and adoption into mainstream platforms. It is an interesting point you raise. On the one hand I get it - if you are having to manually make changes every time then I see how this can be frustrating. What is actually involved on your end when there is a new release? I note that FreeBSD appears to also have a Mailpit package which (from what I can tell) is automated, or at least mostly automated, and their releases usually come within hours of a Mailpit release. > maybe only release if there's notable bug fixes or additional features To be honest, this is mostly how it currently works. The release I just did includes some necessary swagger fixes to allow someone else to build their API tooling, plus a security fix and a few module updates. The release before that a bugfix, and before that inline message previews etc. Basically almost every release adds new features, and they aren't just releases for the sake of it. Could the number of releases be reduced? Quite possibly. What do you believe is a reasonable release cycle for a fast-paced (so far anyway) open source project, and if it is too fast for you to maintain, is there any reason you have to build an AUR package for every release (could you not just slow down your end)?

kerem commented

2026-03-15 12:45:10 +03:00

Author

Owner

@apreiml commented on GitHub (Oct 16, 2023):

To be honest, this is mostly how it currently works. The release I just did includes some necessary swagger fixes to allow someone else to build their API tooling, plus a security fix and a few module updates. The release before that a bugfix, and before that inline message previews etc. Basically almost every release adds new features, and they aren't just releases for the sake of it.

I had the wrong impression, that the last release was only dependency updates. In this case of course I don't want to slow you down in any way.

I'll think about automating the process on my end and of course the AUR packages does not need to be up to date all the time, although the Arch way suggests that.

Also thanks for this awesome software!

@apreiml commented on GitHub (Oct 16, 2023): > To be honest, this is mostly how it currently works. The release I just did includes some necessary swagger fixes to allow someone else to build their API tooling, plus a security fix and a few module updates. The release before that a bugfix, and before that inline message previews etc. Basically almost every release adds new features, and they aren't just releases for the sake of it. I had the wrong impression, that the last release was only dependency updates. In this case of course I don't want to slow you down in any way. I'll think about automating the process on my end and of course the AUR packages does not need to be up to date all the time, although the Arch way suggests that. Also thanks for this awesome software!

kerem commented

2026-03-15 12:45:15 +03:00

Author

Owner

@axllent commented on GitHub (Oct 16, 2023):

That's all good :-) Whenever I release something I also check for both Go and node updates (which there often are), so I usually throw those in too - but I definitely don't create releases just for those module updates. Mailpit development has been moving very fast in the last 10 months or so, and more users resulted in more feature requests - but I do think (or at least hope) it is slowing down a bit now. But every time I think that ... I suddenly get cool feature requests lol.

But I do hear you, and I can feel your pain. Fortunately I have the binary release packages and docker image automated, else I probably would be releasing much less frequently.

Out of curiosity, I noted this in your (now very outdated) fork which was never pushed as a PR to Mailpit. If there is a maintained package available for Arch Linux (I don't know is that is available to the default Arch), and you think it would benefit Arch users, then by all means send a PR to add something to the (current) README and I'll gladly add that.

@axllent commented on GitHub (Oct 16, 2023): That's all good :-) Whenever I release something I also check for both Go and node updates (which there often are), so I usually throw those in too - but I definitely don't create releases just for those module updates. Mailpit development has been moving very fast in the last 10 months or so, and more users resulted in more feature requests - but I do think (or at least hope) it is slowing down a bit now. But every time I think that ... I suddenly get cool feature requests lol. But I do hear you, and I can feel your pain. Fortunately I have the binary release packages and docker image automated, else I probably would be releasing much less frequently. Out of curiosity, I noted [this](https://github.com/axllent/mailpit/compare/develop...apreiml:mailpit:patch-1) in your (now very outdated) fork which was never pushed as a PR to Mailpit. If there is a maintained package available for Arch Linux (I don't know is that is available to the default Arch), and you think it would benefit Arch users, then by all means send a PR to add something to the (current) README and I'll gladly add that.

kerem commented

2026-03-15 12:45:20 +03:00

Author

Owner

@apreiml commented on GitHub (Oct 16, 2023):

Ok. Sounds good :). Lol, I forgot about that one. Yes, I'll send a new PR thanks! Usually arch Linux packages start in AUR. Anyone can sign up and maintain packages there. If there's enough interest, they may be adopted in the community repository.

@apreiml commented on GitHub (Oct 16, 2023): Ok. Sounds good :). Lol, I forgot about that one. Yes, I'll send a new PR thanks! Usually arch Linux packages start in AUR. Anyone can sign up and maintain packages there. If there's enough interest, they may be adopted in the community repository.