ahochheiden 55089cab2f Bug 1872242 - Change how the last segment of milestone_winversion is generated to improve uniqueness r=firefox-build-system-reviewers,glandium ... The previous implementation used days since Jan 1 2000 for the last 16-bit segment. This was not unique enough and caused issues with Antivirus software if two different channels were built on the same day. The new approach uses hours since the last milestone bump and uses the VCS to determine how long ago that was relative to the build time. This means it will always reset when a new cycle begins, but still be unique since the digits in the first 3 segments have incremented. We also now use two of the 16-bits to encode the channel (nightly, beta, ESR, and release). So two channels built within the same hour will still be unique. Using only 14-bits to store the 'hours since version bump', we have about ~682 days from a version bump before we reach the maximum value we can store. If a build is done after that point, the segment value will always be the maximum value for that channel. Differential Revision: https://phabricator.services.mozilla.com/D200989		2024-05-15 16:00:33 +00:00
..
mozversioncontrol	Bug 1872242 - Change how the last segment of milestone_winversion is generated to improve uniqueness r=firefox-build-system-reviewers,glandium	2024-05-15 16:00:33 +00:00
test	Bug 1872242 - Change how the last segment of milestone_winversion is generated to improve uniqueness r=firefox-build-system-reviewers,glandium	2024-05-15 16:00:33 +00:00
.ruff.toml
setup.py