Bugzilla

Hello there!

This numbering scheme was discussed in [1] and :nalexander suggested we archive the result of this conversation back in Bugzilla. 

The original issue was that the scheme doesn't allow 2 nightlies to be shipped within the same hour. I don't think this is a big problem since it's the first time we hear about it in 7 years. 

Here are the important comments of that GH issue: 

**ncalexan commented at 2022-10-07T21:12:30Z**
> > Thank you so much for digging that bug out, @kbrosnan!
> > > If I understand this sentence correctly [...], we will be running out of numbers in July or August 2030.
> > 
> > 
> > I might have misunderstood the sentence after all. This part of [bug 1137898 comment 20](https://bugzilla.mozilla.org/show_bug.cgi?id=1137898#c20) is interesting:
> > > The following patch sacrifices a high order bit to change the version
> > > scheme, winning us roughly 15 years of hourly build IDs before we are
> > > forced to lose another high order bit.  So it's clearly to our
> > > advantage to change the scheme sooner rather than later -- we will
> > > sacrifice 1 bit for 15 years of build IDs, rather than keeping the
> > > current scheme and sacrificing (say) 2 bits for 3 years of build IDs.
> > 
> > 
> > Hey @ncalexan 👋 I know we're half-way through the 15 years and there is no rush here. That said, I prefer to ask now: do we have to do anything once first period of 15 years is over and we lose another bit? In other words, will we have to change the number scheme to accommodate the loss of a high order bit?
> 
> Hi @JohanLorenzo -- sorry for the delayed reply: travel, the All-Hands week, and my current project, have made life very busy :)
> 
> Let me answer the immediate question first. No, we do not _have_ to change the numbering scheme. When we get close to running out of the existing 17 bits, we can elect to overflow into the reserved high-order 0 bit and continue more or less as we are. This would give another `2**17 / (366 * 24) = ~14.92` years of hourly build IDs.
> 
> Can we do better? I think we probably can, if we can incorporate some additional information (from _outside_ the build proper) into the calculation. Two thoughts here:
> 
>     1. We could make the version numbers dense by having a service that provided "next version numbers".  This would give, say `2**17` builds.  Were we to do say 4 Nightly builds a day, that would give us roughly `2 ** 17 / (366 * 4) ~= 60` years of builds.  However, builds are no longer "isolated" in the manner that Mozilla has historically espoused.
> 
>     2. We could make the version numbers denser, but not maximally dense, by incorporating, say, days since January 1, 2030 and then a daily build counter.
> 
> 
> There's some continuum here where we get a dense build number sequence but require centralization through denser but still sparse requiring less centralization all the way to our current sparse build number sequence that requires no centralization (but must discretize the build number space, leading to the "one build per hour" issue).
> 
> Now, do we **need** to do better? I expect not: Android has accommodated additional high order bits with [`versionCodeMajor`](https://stackoverflow.com/q/52630237) in Android 28. I have no idea how quickly we could _depend_ on Android 28, but I'd be inclined to do the simple thing: continue to exhaust our bit space with the current scheme for 6 years, evaluate, and then take our next 15 years, then transition to `versionCodeMajor=1` (assuming Android 28 is reasonable, which in 20 years, I expect it will be).
>
> Oh: when we roll into the high-order bit, we could also take some of the unused lower order bits -- perhaps the x x86 bit and the g API version bit and have a larger space.

**jlorenzo comment at 2022-10-12T10:10:44Z**
> Thank you for your thorough answer, Nick!
> 
> TIL `versionCodeMajor`! I definitely agree on your latter strategy. Android API 28 was branded Android 9 (Pie), which was released 4 years ago and Google no longer provides security updates for it. I sincerely hope Firefox will be past that Android version 6 years from now 🙂
> 
> In any case, thank you for the details about what we could do instead. At the moment, I believe we keep the current numbering scheme since scheduling 2 nightlies during the same hour occurs rarely. I'm going to close this issue, but feel free to reopen if you all disagree 🙂




[1] https://github.com/mozilla-mobile/fenix/issues/27197

Hello there!

This numbering scheme was discussed in [1] and :nalexander suggested we archive the result of this conversation back in Bugzilla. 

The original issue was that the scheme doesn't allow 2 nightlies to be shipped within the same hour. I don't think this is a big problem since it's the first time we hear about it in 7 years. 

Here are the important comments of that GH issue: 

**ncalexan commented at 2022-10-07T21:12:30Z**
> > Thank you so much for digging that bug out, @kbrosnan!
> > > If I understand this sentence correctly [...], we will be running out of numbers in July or August 2030.
> > 
> > 
> > I might have misunderstood the sentence after all. This part of [bug 1137898 comment 20](https://bugzilla.mozilla.org/show_bug.cgi?id=1137898#c20) is interesting:
> > > The following patch sacrifices a high order bit to change the version
> > > scheme, winning us roughly 15 years of hourly build IDs before we are
> > > forced to lose another high order bit.  So it's clearly to our
> > > advantage to change the scheme sooner rather than later -- we will
> > > sacrifice 1 bit for 15 years of build IDs, rather than keeping the
> > > current scheme and sacrificing (say) 2 bits for 3 years of build IDs.
> > 
> > 
> > Hey @ncalexan 👋 I know we're half-way through the 15 years and there is no rush here. That said, I prefer to ask now: do we have to do anything once first period of 15 years is over and we lose another bit? In other words, will we have to change the number scheme to accommodate the loss of a high order bit?
> 
> Hi @JohanLorenzo -- sorry for the delayed reply: travel, the All-Hands week, and my current project, have made life very busy :)
> 
> Let me answer the immediate question first. No, we do not _have_ to change the numbering scheme. When we get close to running out of the existing 17 bits, we can elect to overflow into the reserved high-order 0 bit and continue more or less as we are. This would give another `2**17 / (366 * 24) = ~14.92` years of hourly build IDs.
> 
> Can we do better? I think we probably can, if we can incorporate some additional information (from _outside_ the build proper) into the calculation. Two thoughts here:
> 
>     1. We could make the version numbers dense by having a service that provided "next version numbers".  This would give, say `2**17` builds.  Were we to do say 4 Nightly builds a day, that would give us roughly `2 ** 17 / (366 * 4) ~= 60` years of builds.  However, builds are no longer "isolated" in the manner that Mozilla has historically espoused.
> 
>     2. We could make the version numbers denser, but not maximally dense, by incorporating, say, days since January 1, 2030 and then a daily build counter.
> 
> 
> There's some continuum here where we get a dense build number sequence but require centralization through denser but still sparse requiring less centralization all the way to our current sparse build number sequence that requires no centralization (but must discretize the build number space, leading to the "one build per hour" issue).
> 
> Now, do we **need** to do better? I expect not: Android has accommodated additional high order bits with [`versionCodeMajor`](https://stackoverflow.com/q/52630237) in Android 28. I have no idea how quickly we could _depend_ on Android 28, but I'd be inclined to do the simple thing: continue to exhaust our bit space with the current scheme for 6 years, evaluate, and then take our next 15 years, then transition to `versionCodeMajor=1` (assuming Android 28 is reasonable, which in 20 years, I expect it will be).
>
> Oh: when we roll into the high-order bit, we could also take some of the unused lower order bits -- perhaps the x x86 bit and the g API version bit and have a larger space.

**jlorenzo commented at 2022-10-12T10:10:44Z**
> Thank you for your thorough answer, Nick!
> 
> TIL `versionCodeMajor`! I definitely agree on your latter strategy. Android API 28 was branded Android 9 (Pie), which was released 4 years ago and Google no longer provides security updates for it. I sincerely hope Firefox will be past that Android version 6 years from now 🙂
> 
> In any case, thank you for the details about what we could do instead. At the moment, I believe we keep the current numbering scheme since scheduling 2 nightlies during the same hour occurs rarely. I'm going to close this issue, but feel free to reopen if you all disagree 🙂




[1] https://github.com/mozilla-mobile/fenix/issues/27197