fix __version_as_int__ for >10 minor/patch release vers (resolves #1982)

[mjurbanski-reef]

Bug

#1982

Description of the Change

Uses 1000 base, to fix 6.12.2 __version_as_int__ being larger than one from release 7.2.1 .

Alternate Designs

already discussed in #1982

Possible Drawbacks

If for some reason int16 was used to store the version number it could be a problem, but glance at subtensor code seems to indicate, int32 was used there.

Verification Process

Manual + added simple asserts to prevent similar problems from ever occurring in the future (it will basically immediately explode on import)

Release Notes

• Fix bittensor.__version_as_int__ from release 6.12.x being higher number than one from 7.x line by encoding it using 1000 base instead of 10.
• Deprecated bittensor.version_split - use bittensor.__version__, bittensor.__version_info__ or bittensor.__version_as_int__ instead

[basfroman]

let's use

__version_info__ = tuple(int(part) for part in _version_split)

instead of

__version_info__ = tuple(map(int, _version_split))

in this example it is the same in terms of optimization, but code readability is much better

[ibraheem-abe]

@RomanCh-OT I can make this change when this gets merged. Just waiting for confirmation from subtensor side

[mjurbanski-reef]

Applied;

as for version being u32, AFAIK, that was needed to be checked was in
https://github.com/opentensor/subtensor/blob/0c77062a10cadfbab8507b7dccb2e1ea49848e58/pallets/subtensor/src/serving.rs#L57C9-L57C16
even with prometheus is u32 , but that version number is arbitrary set by node so it doesn't even matter in our context
https://github.com/opentensor/subtensor/blob/0c77062a10cadfbab8507b7dccb2e1ea49848e58/pallets/subtensor/src/serving.rs#L160

So it should be safe.