For deploying our server software, we use .deb files, created with the standard Debian packaging scripts.
We're in the process of changing our version numbers. They were 1.$SHA, e.g. 1.b07be5a5; now they're a bit more semver, e.g. 2.52.1+e0ce8a81 or 2.53.0-pre+0cdb5e4.dirty.
This results in a warning:
Previous package version was Debian native whilst new version is not
What does this mean? Should we care?
Yes, you should care.
If your packages are Debian native (i.e. you build them for Debian and the package's version number is also the version number of each release) then you should stick to a version numbering scheme which preserves this.
If your packages are not Debian native, you should number them accordingly.
Debian package version numbers have the general format
(epoch:)upstreamversion-packageversion(...fluff)
where the dash is significant (and the epoch and trailing stuff are optional); so 1-2 signifies upstream version 1 and the 2 says this is the second Debian package of this upstream version.
Your package versioning scheme where apparently you use a dash for something else is not compatible with this scheme, and needs to be changed one way or another to avoid accidents. Concretely, if the string after -pre is a random hash, you could end up in a situation where an older hash is regarded by dpkg as newer because 1-pre+012new is numerically less than 1-pre+987old.
A concrete suggestion would be to embed a human-readable date and index number before the hash so you have a simple way to avoid this. Then 2.52.1-20191211.01~e0ce8a81 and 2.53.0-20191211.01pre+0cdb5e4.dirty contain the information you want but still sort correctly if there are packages like 2.52.1-20191211.02~adeadbeef or 2.53.0-20191211.02pre+000000 published on the same day with hashes which coincidentally sort lower than those of a previous package from the same day.
If your examples are roughly illustrative, the epoch prefix is not mandatory, but adding it would be a good signal to consumers that these version numbers follow a different convention than those in the previous epoch. (When you switch numbering schemes from 11, 12, 13 to 1.0.15 you really have to add an epoch number in front, resulting in 1:1.0.15 instead.) If you don't put an explicit epoch number, the implied epoch number is zero. So to repeat the previous examples with an epoch number 1 added in front, you'd end up with 1:2.52.1-20191211.01~e0ce8a81 and 1:2.53.0-20191211.01pre+0cdb5e4.dirty.
The suggested convention keeps the semver package version as "upstream" and the individual package builds as the "Debian version". You can omit the dash or replace it with a different character if you want to remain Debian native (i.e. there is no upstream, and the Debian package version is the authoritative version number).
The details of the Debian version numbering system are documented in the Debian Policy, Section 5.6.12 Version