CF packager handled `file-date-integer` badly
ascott18 opened this issue · comments
Strap in for a ride - this is ultimately the root cause of ascott18/TellMeWhen#1873. More specifically, its the reason that this user somehow triggered an upgrade to LDT after having already loaded LDT-Unit.
The current packaged release of LibDogTag-3.0 as uploaded on Curseforge, v90000.2, has a MINOR_VERSION offset in LibDogTag-3.0.lua of 2016052752106. Broken apart by each component of the date, that's 2016 05 27 5 21 06. Wait, why is the hour only one digit?
The Curseforge packager. That's why. That version of LDT (and all versions prior) was packaged with the CF packager, not the BigWigs packager + GH action. Or, at least I think it was because the v90000.2 tag doesn't look like a release created by BigWigs packager.
The Curseforge packager doesn't seem to have always been broken in this way. Here are the MINOR_VERSION offsets for LibDogTag-3.0.lua that I'm seeing for a random selection of zips from Curseforge:
| Version | Offset | Note |
|---|---|---|
| 70000.1 | 20160527052106 |
|
| 70100.1 | 20160527052106 |
|
| 70200.1 | 20160527102106 |
Timezone change for some reason? |
| 80000.1 | 2016052752106 |
Timezone back to what it was, but now its dropping leading zeroes. |
| 80300.1 | 2016052752106 |
|
| 90000.1 | 2016052752106 |
How do we know that the BigWigs packager behaves correctly? Because running TZ='' printf "%(%Y%m%d%H%M%S)T" "1464326466", the actual code used by BW packager, does indeed output 20160527052106 with the leading zero correctly in place on the hour.
- As a side note, BigWigs packager appears to be setting this timestamp to the time of the last commit to the entire repo, not the last commit to the specific file being processed. However, we don't really care about this.
Its important to note now that the way that ThreatPlates was embedding LDT was by copying a downloaded version from Curseforge and checking it into the repo. So, the version embedded into TPTP had the bad MINOR_VERSION that was too small by a factor of 10.
So, the scenario that I imagine led to ascott18/TellMeWhen#1873 happening is:
- ThreatPlates loads LDT with a broken, too-small minor version
- ThreatPlates loads LDT-Unit
- TellMeWhen loads LDT with a correct minor version, triggering the upgrade.
The only part here that doesn't make sense is - why did TellMeWhen seemingly load after TidyPlates_ThreatPlates? Maybe something earlier in the load order had an optional dependency on TPTP? Doesn't really matter, though. To bring this to a point...
TL;DR: Curseforge Packager sucks and spit out bad timestamps. LDT hasn't yet been published with the BigWigs packager, and so probably should be done so soon because the packaged version of LDT 70200.1 has a higher LibStub minor version than 90000.1. Perhaps after you've had a chance to peek at #1?
Super fun. I bet that was a blast to track down (/s). I'll get a new version of this and LDT-Unit pushed out today.