It seems that this line of document needs to be changed after #3335.

These two docs updates might be worth squeezing in last minute for this release?

• docs: Example - Integrating Crowdsec #3651
• docs: Debugging - Correctly starting DMS #3654

If my one is approved before @georglauterbach responds, I'll merge both and update the changelog here 👍

@polarathene please update this PR (Changelog) and merge. Keep the feature-freeze labels though. I will publish the tag afterwards after I will have updated the release description.

@polarathene please update this PR (Changelog) and merge. Keep the feature-freeze labels though. I will publish the tag afterwards after I will have updated the release description.

That's bad. A new tag/release should be created directly after merging this PR. At the moment, the update-check notifies about the v13 release, however there isn't a new image to download yet.

At the moment, the update-check notifies about the v13 release, however there isn't a new image to download yet.

Sorry, I wasn't aware of that and just following instructions 😓

It might be better if we query the github releases for a new release instead?

# `-H` => Request JSON response
# `-L` => `releases/latest` is a redirect (unlike direct release tags)
$ curl -LH "accept: application/json" https://github.com/docker-mailserver/docker-mailserver/releases/latest

{"id":42,"tag_name":"v12.1.0","update_url":"...","update_authenticity_token":"...","delete_url":"...","delete_authenticity_token":"...","edit_url":"..."}

With that we can probably use tag_name, since it's JSON just throw that into jq:

$ curl -sLH "accept: application/json" https://github.com/docker-mailserver/docker-mailserver/releases/latest | jq -r .tag_name
v12.1.0

Now you have the same value for LATEST to handle here?:

While unlikely to be an issue, if we ever do make releases that aren't sequential (eg: a v12.2.0, or more realistically a 12.1.1 security patch), querying releases/latest perhaps won't work as well since it'd get an older release, even if we had released a newer v13 update moments prior.

If you query the next patch/minor/major (releases/v13.0.1, releases/v13.1.0, releases/v14.0.0) with 3 requests instead, you'd have something a bit more resilient to that concern.

Big thanks to everyone involved! This project is definitely the easiest and quickest way of installing a personal or SOHO email server with all the guarantees. Keep on team! 🎆

It might be better if we query the github releases for a new release instead?

Afaik the API is rate limited. If there are other things running on the same host using the API, that can lead to problems. I would stick with the current approach. Also it's rather unusual to merge the release PR, but not creating a release 😉

I will take care within the next hours.

That commit message though:

😆😆😆😆😆

Afaik the API is rate limited.

What rate limit?

• You're probably thinking of the API service at https://api.github.com?
• If it were rate-limited like the actual GH REST API, it would include that information in the response?
• Even then it's 60 requests per hour, if the DMS host were to exceed that from other activity it's likely the admin is experiencing that problem elsewhere too.

However, in this case it's just a standard web request to Github. It is effectively no different of a request than the one you're already making for a file at the repo?:

Which you default to once a day:

I would stick with the current approach.

Your approach is what caused the false-positive for a new release being available. The approach I've suggested doesn't have any notable regression but avoids the problem scenario you noticed from occurring?

Seems like it'd be better to query the actual latest GH release and compare that to the VERSION.

VERSION may be better suited as an ENV DMS_RELEASE in the Dockerfile (which could additionally be provided as an ARG since the CI should have the tag on release, avoiding a past issue where VERSION was not incremented with a release tag).

Also it's rather unusual to merge the release PR, but not creating a release 😉

Already stated that I was following @georglauterbach request. If the version check is handled the way I've proposed it fixes two release bugs related to VERSION experienced so far.

It shouldn't matter if there is a delay between a release PR being merged and when a release is officially tagged/published. This had a less than 15hr delay which I have no issue with, nothing else was being merged inbetween.

It is definitely my fault that there is a delay here between the merging of this PR and the release; I apologize for that - it won't happen again.

You're probably thinking of the API service at https://api.github.com?
If it were rate-limited like the actual GH REST API, it would include that information in the response?

Yes, I've things mixed up 👍

My main point was just, that the VERSION file shouldn't be updated, when not making a new release (makes no sense). Just do both at the same time and everything is good. Fixing problems (enhancing the update check) that aren't real problems seemed unnecessary to me.

That said, it makes no difference to me checking the version file or the latest release as you suggested. Normally the results shouldn't differ. If you however like to change the check, go for it 👍

Edit: After more thinking, I came to the conclusion, that checking the release is more logical and therefore better.

Already stated that I was following @georglauterbach request.

I didn't want to offense you or Georg in any way. I just wanted to make aware of this and let Georg know, not to delay the release for too long. It's really no big issue to make the release some hours later. We are humans after all.

I apologize for that - it won't happen again.

Again, if I sounded too harsh, that wasn't my intention! ✌️

My main point was just, that the VERSION file shouldn't be updated, when not making a new release (makes no sense). Just do both at the same time and everything is good.

That can be automated:

          build-args: |
            DMS_RELEASE=${{ github.ref_type == 'tag' && github.ref_name || 'edge' }}
            VCS_REVISION=${{ github.sha }}

FROM stage-main AS stage-final
ARG DMS_RELEASE=edge
ARG VCS_REVISION=unknown

# ARG invalidates cache when it is used by a layer (implicitly affects RUN)
# Thus to maximize cache, keep these lines last:
LABEL org.opencontainers.image.revision=${VCS_REVISION}
LABEL org.opencontainers.image.version=${DMS_RELEASE}
ENV DMS_RELEASE=${DMS_RELEASE}

VERSION="${DMS_VERSION}"

  [[ ${ENABLE_UPDATE_CHECK} -eq 1 && ${DMS_RELEASE} != 'edge' ]] && _register_start_daemon '_start_daemon_update_check'

You could of course create the /VERSION file instead of an ENV this way, but with an ENV it's more clear that the service isn't used with :edge (doesn't really make sense to?)

Fixing problems (enhancing the update check) that aren't real problems seemed unnecessary to me.

1. :edge should not care about the update process, these concerns should not have been raised:
   • bug fix: remove exit 0 from update-check.sh #3659
   • bug fix: push :edge when VERSION is updated as well #3662 (review)
2. In the past a release was made without bumping VERSION accordingly.
   • The fix was to publish a new patch version/tag.
   • Wouldn't be a problem with improved update check logic.
3. This concern you raised with the release PR and delayed tagging of the release would again be a non-issue.
   • :edge unaffected since it's not actually tied to the /VERSION file it compares to Github VERSION with.
   • Tagged releases wouldn't notify until a new tagged release is actually published.

All concerns related to the update checking script, all resolved by better integration + checking.

Normally the results shouldn't differ. If you however like to change the check, go for it 👍

Agreed, I'll raise a PR so these concerns don't occur again.

EDIT: Done 🚀

Edit: After more thinking, I came to the conclusion, that checking the release is more logical and therefore better.

🎉

I didn't want to offense you or Georg in any way. I just wanted to make aware of this and let Georg know, not to delay the release for too long. It's really no big issue to make the release some hours later. We are humans after all.

No offense taken! 😄