docs: pin libmuslim downloads to the 2026.08.18 release - #31
Merged
Conversation
The download commands pointed at v0.1.0, which predates the time formatter fix. A reader following the quick start got a header where a high-latitude time prints as "00:-6", while the reference pages on this site described the fixed behaviour. The docs and the file they told you to fetch disagreed. Also explains why the tag and the header version differ, at the point where the reader first sees both. The tag is a calendar date, each header carries its own semantic version, and 2026.08.18 contains prayertimes.h v0.1.1 alongside two headers still at v0.1.0. Without a note that reads as a mismatch rather than the intended design. Both pinned URLs were fetched to confirm they resolve and that the served prayertimes.h banner reads v0.1.1.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…inned tag A pinned tag in the docs goes stale the moment a release is cut, and it just did. The commands pointed at v0.1.0, which predates the time formatter fix, so a reader following the quick start got a header printing "00:-6" while the reference pages on this site described the fixed behaviour. Fetching from releases/latest/download removes the failure mode rather than resetting the clock on it. The pinned form is kept and shown, because a build that has to be reproducible from the command alone still needs it. This uses release assets, not raw.githubusercontent.com, which has no latest ref. Both URL forms were fetched to confirm they resolve, that the served prayertimes.h banner reads v0.1.1, and that the bytes match the repository. Also explains why the release tag and the header versions differ, at the point where the reader first sees both.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the libmuslim
2026.08.18release.The docs and the download disagreed
The download commands pointed at
v0.1.0, which predates the time formatter fix. A reader following the quick start got a header where a high-latitude time prints as00:-6, while the reference pages on this site, updated in #30, described the fixed behaviour.That is the worst version of a stale pin. The documentation was not merely old, it was wrong about the file it told you to fetch.
Both pins now point at
2026.08.18, and both URLs were fetched to confirm they resolve and that the served banner readsv0.1.1.Explaining the two numbering schemes
libmuslim now uses calendar-dated release tags with per-header semantic versions, so
2026.08.18containsprayertimes.hatv0.1.1alongsidehijri.handtimezone.hatv0.1.0.Someone who runs the
curlcommand and opens the file sees a tag and a banner that do not match. Without a note that reads as a mismatch rather than the intended design, so the note goes right below the download block where both numbers are first visible together.Site builds clean.