Since commit c13a605, appstreamcli is complaining on an absent date which makes complete sense for the finale file validation. Nevertheless we usually create the <release> tag as early as possible in advance. One of the reasons is that the <description> can be (and should be!) localized so we need to leave time to translators by filling the release text as soon as we know it.

At this point, we might not know the release date yet. Even if we had a global timeframe, it will likely shift as we discover last-minute issues. We could just set a random date, but it means that (1) we need to edit it again, possibly several times, as we get closer to the release, making useless commits and (2) the worst case is that if we forget to edit the date (because the appstreamcli test didn't return any error), we might release with wrong release date in metadata.

On the other end, if we were allowed to ignore the date with a specific relaxed check, then when we are preparing our actual release, the test would use the stricter check requiring a date. This way, we can prepare the <release> tag without knowing the date even long in advance, and still get the date validation upon release. This is possible in GIMP (my use case) since we use even micro version for release versions and odd micro versions for dev code.

So for instance, most of the time, our build would test our XML, ignoring the release date, with:

appstreamcli validate --relax desktop/org.gimp.GIMP.appdata.xml

And when we bump the micro version, preparing for the release, it would test with:

appstreamcli validate desktop/org.gimp.GIMP.appdata.xml

Hence allowing us to spot the missing date (much better than having a random date we set long ago which would not trigger any kind of warning).
For the record, appstream-util had the validate-relax mode which was doing just that (among other differences), i.e. ignoring the <release> date.

Thanks!