game versioning scheme should be a uint_8[3], not a float #12

Closed
opened 2025-10-27 14:48:19 -04:00 by VIA256 · 1 comment
Owner

since its a float that represents it as M.mp (ex: 2.2.2 = 2.22), minor and patch can only reach 9 before carrying.
I would rather not have to worry about that.

also since its a float there is some possibility of inacurracies when comparing versions.
although this is very unlikely (if not impossible) because we only go to the hundredths place. it just seems wrong (wow what a great argument)

since its a float that represents it as M.mp (ex: 2.2.2 = 2.22), minor and patch can only reach 9 before carrying. I would rather not have to worry about that. also since its a float there is some possibility of inacurracies when comparing versions. although this is very unlikely (if not impossible) because we only go to the hundredths place. it just seems wrong (wow what a great argument)
Author
Owner

thinking on how to transition from semantic float versioning to semantic uint_8[3] versioning and I have a basic plan
in the upd3 add a line: sv=4.0.1 for the next patch version and set the float version to this as well: v=4.01.
then change the logic in the next patch release to regognize sv instead of v in upd3.
as new versions go by, the upd3 sv will be updated while the v will stay v=4.01 just in case.

thinking on how to transition from semantic float versioning to semantic uint_8[3] versioning and I have a basic plan in the upd3 add a line: `sv=4.0.1` for the next patch version and set the float version to this as well: `v=4.01`. then change the logic in the next patch release to regognize `sv` instead of `v` in upd3. as new versions go by, the upd3 `sv` will be updated while the `v` will stay `v=4.01` just in case.
Sign in to join this conversation.
No description provided.