Mailu: Proposal: Use semantic versioning

[boldt]

Proposal

Looking into the tags, I realized, that you always push into the the main tags 1.6 and 1.7. Like this, it is hard to determine, whether my installed version has an update or not.

Thus, with semantic versioning it is easier to check, whether there is a new version, e.g., an update, available. Especially for automatic tools. Also if an update fails, it's possible to rollback to the previous version (of course with a backup).

As a reference, i can recommend mysql. They do a great job with versioning:

• https://hub.docker.com/_/mysql?tab=description

Examples

• I have a working 1.6 and I update to a broken 1.6. There is no way to roll back to the working 1.6.
• If have a working 1.6.1 and I update to a broken 1.6.2. Like this, there is an easy way roll back to the working 1.6.1

[muhlemmer]

In principle, Mailu is nothing more then a bunch of configuration scrips. (With the exception of the Admin project). For instance, we pin an Alpine version in our docker files, but Alpine Linux always gives us the newest versions from their repository for that version. Let's say they update Dovecot package for a bugfix, then automatically we will pull the newer version. Even without having a commit to Github.

We started cron job builds some time ago, as it does happen that some security fixes were pending too long and nobody was around to bounce a new build.

I can see the general advantage of semantic versioning. But even if we manage to pin Alpine package version, or disable cron jobs, it will put a huge administrative overhead on the project. Contributor time is not a constant and usually happens in waves.

What I personally might agree to, is a date suffixed versioning / multi tagging. So we could have something like:

• 1.6: Always the latest 1.6 build.
• 1.6-20190927: Today's build for the 1.6 branch (if there was any).
• latest: Latest build of the latest stable. Which would equal to 1.7 and 1.7-20190927.
• master: Un-versioned dev builds.

Something like this should be pretty simple to automate in the build scripts. And users then have the freedom to stick / downgrade to a certain date in the past.

[boldt]

Especially for such kind of "hidden" updates, which you describe with Alpine and Dovecot, needs some way to determine. How about 1.6.20190927 instead of 1.6-20190927? This will follow semantic versioning and can be used by automatic tools.

[kaiyou]

Sounds fair. I would suggest the default setting is still to use branch versioning, so that most people benefit from updates just by running pull, or we will start getting loads of outdated and dangerous Mailu setups.

[micw]

A good practice is to use multiple docker tags per image. e.g. 1.6.20190927, 1.6 and "stable" for the 1.6 builds.
Instead of 1.6.20190927 we could also tag stable releases in the stable branch (should be not too much work since it's not committed frequently to these branches). Tagged builds have also the advance that changes between releases can be seen in the github changelog.

[kaiyou]

Agreed. Except for the stable tag, which cannot be trusted if we make breaking changes to the way we run containers. In that case, the stable tag would be unstable by nature.

[micw]

I did a short test with travis. If a branch is build, the branch name is in TRAVIS_BRANCH and TRAVIS_TAG is empty. If the build is a tag, both, TRAVIS_BRANCH and TRAVIS_TAG contains the tag name. There is no (easy) way to check on which branch a tag is.

We could do the following:

1. Selected branches are always always build and pushed with the branch name (master, testing, staging)
2. Tags are always build and pushed, image is tagged with the tag name (e.g. 1.6.1).
3. If the tag name is a semver, it's also pushed without patchlevel (e.g. 1.6)
4. versioned branches (1.6, 1.7, ...) are build but not not pushed

This gives the following result:

• instant non-versioned build for testing (master, testing, staging)
• option to tag specific master versions (e.g. 1.8-alpha1)
• selected, versioned builds from the versioned branches
• "meta" versions (e.g. 1.6) that always have a corresponding version tag (1.6.1)

Edit: I think something like 1.6.20191022 based on build timestamp is not a good idea because it:

• has no relation to a specific git commit
• reflects the build date, not the commit date
• will be overridden by a new build on the same day
• will create a lot of images, so some kind of housekeeping should be implemented

[boldt]

The issue with two commits on the same day is obvious.

Maybe it makes sense to have a look on how other projects are doing it, e.g.

• Apache: https://hub.docker.com/_/httpd
• Postgres: https://hub.docker.com/_/postgres
• Nextcloud: https://hub.docker.com/_/nextcloud/
• Node: https://hub.docker.com/_/node

I guess, they all provide a good practice with multiple tags per image. As people are familiar with this kind of taging, I suggest to do it as well.

[micw]

Maybe we should consider to switch to a version scheme like nodejs. Having a major release every then and when, having minor releases every time we add something notable (non-breaking), and having patch releases for small fixes. That would mean that mailu 1.7 becomes mailu 7. It would much better reflect the changes in a "semver" way.

[briantopping]

I just ran into this today. I was trying to figure out why Roundcube is not working with the current Helm charts and realized that the mailu/nginx:1.7 tag got updated yesterday. Agree with what @muhlemmer was saying about this being a collection of scripts and the best way to keep those scripts up-to-date is to be following changes. That said, unless checkins for every push to Docker hub are perfect and all permutations of configs are known to work, I'd rather be the one to change my image tag and know exactly how to roll it back than the alternatives.

While writing this, I came up with the idea for #1464 as well.

[Nebukadneza]

Hi There,

The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.

To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.

In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the :smiley: icon to the top-right).

• 👍️ if you need this to be able to use Mailu. Ideally, you’d also be able to test this on your installation, and provide feedback …
• 🎉 if you find it a nice bonus, but no deal-breaker
• 🚀 if you want to work on it yourself!
  We want to keep this voting open for 2 weeks from now, so please help out!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[briantopping]

So I guess we've moved from a lack of response on valid issues to spending time implement stalebot to close issues. As @AndrewSav said in this comment:

it's not right to close an issue just because currently no one can work on it. It does not become a non-issue because of that and if you close it some one will come and open a new one. There is no benefit is closing issues without fixing just for the sake of closing

So if what you're trying to do is somehow make Mailu _look complete_ because there are no open issues, this will be effective. If you want Mailu to be the best mail server out there, don't be so anxious to close issues that people spent good time thinking through and articulating. It's rude and people will start to look elsewhere for solutions.

If you don't like an issue, close it as "will not fix". Otherwise, please fix /lifecycle frozen. Thank you!

[Nebukadneza]

Please move the offtopic discussion to #1642 to keep this open for on-topic discussion.