Docker-mailserver: Proposal release channels

[johansmitsnl]

New changes introduce new issues or it might even break things that should not.
Right now the master branch is linked to the docker latest tag. There is no edge of development branch available and it might be useful to create one.

My proposal is to link master to docker:latest and add a new branch stable linked to the docker:stable.

This issue is to see if this sounds good and if there are suggestions? We could do a monthly release cycle of master to the stable branch to introduce new features to stable users. Cherry-pick hotfixes if it breaks something urgent.

What do you guys thin about it? @tomav @17Halbe @mwlczk

[mwlczk]

Hi @johansmitsnl this sounds good. and i don't mind to have an extra branch with more "edge"-development.
Here is the thing though: When do we decide to move new functionality to a stable branch? At some point we have to do it. In that moment it would break the stable branch for some people even if the patch was completely fine.
What if we have a latest (or edge) and additionaly start numbering the stable-branches with versions. We start a CHANGELOG.md and comment the differences merged into the versions there. Only Hotfixes/Urgent/Security-fixes would be allowed to older Versions. And only the last and one older version would be in Focus of fixes.

People should really not upgrade their servers on daily basis on latest stream - this is really dangerous.
If someone wants a new feature, he really has to switch to a newer and be aware of the changes. staying on a fixed version of the server would allow in this case to get security fixes every night still.

[johansmitsnl]

The decision to release features could be made based on the time in development. Example: I only merge every 2 weeks new features and before I start merging the issues with the last pulled features should have been solved and I create a release of that stable/development version.
Then the window opens again to pull in new changes and we start testing them again for 2 weeks.

On the docker hub there is a trigger when the base image (debian) updates it triggers a rebuild so security of the stable branch should not be an issue. The idea is a rolling release but having tested code in production environments of people that don't mind to run this branch, thats why I prefer to use latest for this because people prefer most of the times this tag. Creating new versions that people get stuck on does not seem right, but to use only 2 branches and tags on the release if people want to get stuck on a version lets the users decide that they want to run.
With the semver versioning we could also indicate that there are breaking changes or not.

[boaorm]

Great! Thanks for initiating this! I would love to have a stable branch with security updates only :)

[17Halbe]

Sounds good and reasonable!
The only thing I would be worried about, is if we are enough people on the testing branch to really test the new features. We would need many different setups to be tested on the dev branch in production, otherwise we just delay possible breaking changes to be merged to latest/stable. See: Works for someone but not all of us ;)
That's not an argument against a dev branch, just something to consider. (It's still better than letting normal users be beta-testers! ;) )
So :+1:

[johansmitsnl]

That's true. But most users have latest now and they might be lazy in switching so I guess we keep a good userbase in dev.

[mzedeler]

I would really like if the releases are backwards compatible. On one hand, I want my server to pick up the latest changes to stay up with the latest security related patches, but it becomes a game of whack a mole if stuff breaks on every release.

Another way to see this is that we should consider how the release cycle should look like in the consumer end. Should people just track the latest stable release automatically or do we expect them to follow manual steps every time there is a release?

I think that a good balance between the two could be to expect all minor versions to be feature compatible and not require any human intervention and ask people to update those automatically and only release breaking changes in major versions.

[johansmitsnl]

@mzedeler agree. When possible we keep them backwards compatible, but sometimes changes are needed.
Also with better release management and changelogs we want them easier to track when incompatible changes where introduced but we want to keep those to a minimum and with introducing tags you could also use a tagged release. Currently waiting tomav to make the changes to the docker repo.

[mwlczk]

what about the two week rule? did the time pass, so we could merge some of the PRs into the stable branch?

[johansmitsnl]

@mwlczk there is still an issue with the tag builds, the 3.0.0 tag is not build on the hub. Because I don't have access to the docker hub I'm waiting to have this fixed. Then I can start merging new commits into stable and create releases for this.

[johansmitsnl]

Docker is building all tags as we speak: https://hub.docker.com/r/tvial/docker-mailserver/builds/
Updated the changelog and made changes to the versions that break behaviour
https://github.com/tomav/docker-mailserver/blob/master/CHANGELOG.md with the commends and issues that go with it.
New releases will have more extensive details to the changelog. Hoping it is much clearer about the changes and fixes for the future :-)

[dmcgrandle]

This is excellent work guys. Looking forward to a much more predictably stable docker image in the future. :)