[tor-bugs] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
----------------------------------------------+----------------------------
 Reporter:  gk                                |          Owner:  tbb-team
     Type:  defect                            |         Status:
                                              |  needs_revision
 Priority:  Medium                            |      Milestone:
Component:  Applications/Tor Browser          |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201608  |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+----------------------------

Comment (by gk):

 Replying to [comment:23 boklm]:
 > Replying to [comment:21 gk]:
 > >
 > > I think we should care about getting a valid date out of it (at least
 it can't hurt). What I do not understand is the need for hard-coding the
 oldest supported ESR version. Why can't we extract a version from the
 parameter the script get passed anyway (in fact the major ESR version does
 already get extracted)? It seems to me there always will be times where
 the alphas and the stable series share build ids which does not seem to be
 bad to me. So, what is your motivation for hard-coding that number?
 >
 > Maybe the "oldest support ESR version" name is confusing. It is just a
 number that we subtract to the major ESR version to make it less than 30
 (I was wrong in my previous comment, the major ESR version is not used as
 the month but as day of the month). We don't want this number to be based
 on the current version, because for instance when we release a version
 based on ESR 52, we still want to continue subtracting 45 so that the
 buildid for ESR 52 releases is bigger than for ESR 45 releases.
 >
 > For ESR 45 releases, the buildid will start with 20160101 or 20170101
 (for the releases made in 2017). The ESR 52 releases made in 2017 will
 have a buildid starting with 20170108. In 2018 we will change $oldest_esr
 to 52 and ESR 52 releases will have a buildid starting with 20180101, ESR
 59 releases a buildid starting with 20180108.

 I see. So, bumping the hard-coded value is year-bound, right? More
 precisely: every two years starting with 2018 we increase the hard-coded
 value by 7, correct? If that's the case then we can hard-code the current
 year and then we compare the year extracted (like done with
 `COPYRIGHT_YEAR`) with the one we hard-coded: if the extracted one is the
 hard-coded one + 2 we add to the hard-coded "old-ESR" value 7 if + 4 then
 we add +14 etc. If incrementing is not year bound (maybe it should not
 because ESR release are not happening exactly every 12 month) I guess we
 could construct something similar taking ESR versions into account (like
 every two major ESR versions we can add 7 to our hard-coded value.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19528#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online