We need to define a non-deterministic MID indicator

[doroved]

Hi!
I am using mid 3.0.1.
Several users of my application have experienced their mid changing after:

1. macOS update from 12 to 15
2. On an AIR M-series macbook, the mid was changed for no apparent reason and reverted back again

If anyone has encountered this, have you tracked which parameter is changing?

I will do a logging of the mid metrics in my application and compare them on each run.
Once I figure out which parameter is not deterministic, I will remove it, which will cause the mid hash to change, this will be version 4.0.0

[doroved]

#8 (comment)

[ntamas]

Thanks a lot!

To ease the migration for newer versions of mid, I wonder whether it would make sense to introduce a versioning scheme for UIDs and make it so that later major versions of mid can return UIDs according to the behaviour from earlier versions. The UID scheme in mid@3.0.0 could be version 1, and the new variant in mid@4.0.0 could be version 2. Calling a special function like mid::get_versioned(1) would return the UID as it was before mid@3.0.0, and mid::get_versioned(2) would return the UID as it is since mid@4.0.0. This is not API-breaking but it would allow the users to upgrade your crate beyond major versions if they always stick to the same version number in mid::get_versioned(...) if backward compatibility is an issue.

Implementation-wise, MidData could gain a version_mask: Vec<Range<u8>> field with a length identical to the result field. The i-th item in version_mask could identify the version range in which the corresponding item in result should be mixed in the final hash. This allows the addition and removal of fields in result in future versions while keeping compatibility with older versions and not requiring significant code changes. (It would be clearer to change the type of result in MidData to accommodate a version range but that would be API-breaking so it could go only in mid@5.0.0).

If you feel that this is a good direction to go, I can try to wrap up a PR in the next few days.