fix __version_as_int__ for >10 minor/patch release vers (resolves #1982) #1993
Conversation
bittensor/__init__.py
Outdated
| + (10 * int(version_split[1])) | ||
| + (1 * int(version_split[2])) | ||
| _version_split = __version__.split(".") | ||
| __version_info__ = tuple(map(int, _version_split)) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
@RomanCh-OT I can make this change when this gets merged. Just waiting for confirmation from subtensor side
There was a problem hiding this comment.
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.
Bug
#1982
Description of the Change
Uses 1000 base, to fix
6.12.2__version_as_int__being larger than one from release7.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
bittensor.__version_as_int__from release 6.12.x being higher number than one from7.xline by encoding it using 1000 base instead of 10.bittensor.version_split- usebittensor.__version__,bittensor.__version_info__orbittensor.__version_as_int__instead