The user-relevant* update entries since the last list file update are listed at the beginning of the file.
This is correct.
The list at the end of the log file comprises all user-relevant* update entries since 2015.
Not all of them, but just the most recent one for each route .listed as traveled.
So for example, if melvin.list has one line,
TX I-69E PolkSt 56melvin.log will have the 2022-05-16 update where it was "Extended northward from Yturria Co Rd to Exit 56", but not the 2021-12-19 update where it was "Extended northward from US 77 Business (Raymondville) to Yturria Co Rd."
Concurrent routes such as US77 will not be listed in the log file; the logic here is that the only part relevant to Melvin is what's concurrent with I-69E, and I-69E is good enough to let him know there's an update to beware of. Updates for other parts of US77 will just hurt the signal-to-noise ratio.
If you want to get more info about older updates, you'll have to go to
the updates page.
Long-term, I'd like to add functionality to the updates page to display only updates relevant to a specific user's routes. All of them, back to 2015.
Problem is, it will take some adjustments to the database and site update program to enable this. The DB currently has no way of "knowing" that Melvin didn't explicitly .list US77. So it's been a low priority.
If this were done now, users would be faced with lots more irrelevant noise.
Does that part of the log just keep growing bigger and bigger the more routes we add?
Essentially, yes.
It can can stay the same size if we manage to only add routes that have never been listed on the updates page, such as ME206 or TX US83. But if these routes are updated in the future... Does it ever get trimmed down?
No.
Do route notices in there "expire" at some point?
Not really. A notice will go away only if superseded by a more recent one. So maybe think of them as occasionally getting "updated", but never expiring.