stackage badges pointing to lts-3 still
Closed this issue · 9 comments
I don't follow. Here is what I see in the hlint's README:
- The bagde's image is showing the version of hlint (1.9.31) which is included in the latest LTS (lts-5.9). That's what https://www.stackage.org/package/hlint/badge/lts is resolved to.
- Clicking on the badge takes you to the package page on stackage, information on which is completely consistent with what the badge displays.
Is there something wrong with that, or am I not seeing something? I really can't find anything in those badges that would refer to lts-3.
The badge reads for me "Stackage lts-3 1.9.22" (on both Firefox and Chomium) - so you see something else?
That's interesting. To me it reads Stackage | 1.9.31. Even in your message.
I curled https://www.stackage.org/package/hlint/badge/lts?label=Stackage and after some gazing at the returned xml I can confirm that stackage replies with correct badge.
There are some middlemen who are likely to be causing this problem:
- Github's caches. Here is the url which github puts in the rendered version of hlint's README (at least for me). However it also reads as
Stackage | 1.9.31. - Browser caches. Well, try to clean them or force-reload.
- ISP caches.
IIRC, it's not the first time when we encounter similar issues, so I think we should add the headers which would help those guys at invalidating their caches properly.
Here is a relevant issue github/markup#224, I remember reading that before, but I absolutely forgot to take care of it.
Hmm. I actually did try to take care of it in #141. Seems like it wasn't enough, adding ETag header would make a lot of sense. Travis and some other services also set Pragma: no-cache but I guess in our case we wouldn't mind some caching as long as ttl is a few hours.
Ah right I see what you mean - github caches images put in wiki markup right.
Looks okay to me now, thanks - though I haven't checked now very extensively.