Another option is to use of a date substring at the end of releases and dev builds, or you could simply use alphabetical sub-string tags such as "Alpha, "Beta", "RC", "Release"

This would also solve the problem.

They're not alphas, betas, or release candidates, though. They're just somebody's random compile.

On balance I think changing this would make things worse. I don't want my custom compiled copy in ~/github/CKAN/_build/ckan.exe to be overwritten by a download from the internet.

Do you have some secret version of the CKAN ? :)
Then just don't update it, when it will say what there is a new version.
But a casual comrade developer, that has some randomly compiled version, want to have notification, which will suggest him to update to the last official release when it will be released

If you are running a release, it will auto-update when a new release comes out. It you are compiling it, you are bypassing the release mechanism, and will need to keep compiling it. How is this confusing?

If you are compiling it, you are bypassing the release mechanism

I am not, compiled version is in between of 2 releases.

So it's not a release, is it?

But I could imagine an indication for non-releases, combined with no automatic, but possible manual updating.

Compiled version is not a release.

There is a CKAN option on the settings — "check for SCAN updates". And the button for checking updates.
if user don't want updates, whatever they has compiled in between or released version, they just disable automatic updates, and don't click the button.
if user want to update, they expect to click the button or enable checkbox and get an update.

Released version is an update for every compiled in between version, is it?

So my suggestion would just need a ".<buildNumber>" or similar (kinda like @Ruedii proposed) added to the version string (edit: in the CLI we have it already, we would just need to use it in the update process...)
Deselect searching for updates if you want (like you can already).
And if you keep it selected, it just behaves like normal release versions.

This would solve @yalov's issue, and @HebaruSan could keep the custom builds.

It is certainly possible to use a different number in between releases to what is used for the release itself. It just means updating the version number in CHANGELOG.md as part of the release process. The only people this affects are those that occasionally compile CKAN and want to then automatically get the release when it drops.

Process updated here