mirror of
https://github.com/mudler/LocalAI.git
synced 2026-10-28 17:18:49 -04:00
mudler's LocalAI [bot]andEttore Di Giacinto
94d5affcea
* feat(website): split the site, move docs to /docs, add a landing page The Hugo docs site has always been localai.io itself, which left nowhere to explain what LocalAI is or show what the team builds. This adds a separate marketing site at the root and moves the documentation under /docs/. Docs: The existing site keeps its content tree and its Relearn theme, and now builds with baseURL <root>/docs/. Its _index.md, which held a hand written landing page, becomes a real documentation home. Every previously published URL keeps working. GitHub Pages has no server side rewrites, so .github/ci/gen-redirects.sh walks the built docs output and leaves a meta refresh plus a canonical link at each old root path. It covers bare .html files too, which is what keeps /gallery.html alive, and it never overwrites a path the marketing site already owns. Website: A second Hugo site under website/ with its own layouts and no external theme, so the marketing side does not have to fight Relearn's home rooted menu and asset pipeline. CI builds both and merges them into one Pages artifact. The design is derived from the project logo rather than invented: the navy of the triangle, the cyan of the llama, the purple of the speed bars. Those offset bars became the motion signature. The background renders a real depth-anything.cpp depth map as contour lines and switches to a locate-anything.cpp style detection overlay over the engines section. Also included: an /engines/ index driven entirely by data/engines.yaml, a /blog/ section with five posts written from the release notes and the engine benchmark suites, install.sh and a Kubernetes manifest since the site advertises both, and a rule in .agents/ that release preparation now includes a blog post and demo clips. Every figure on the site is derived from the repository or the GitHub API, not from memory. Correcting them against their sources found one error in README.md: voxtral-tts.c is text to speech, not speech to text. Signed-off-by: Ettore Di Giacinto <mudler@localai.io> Assisted-by: Claude Code:claude-opus-5 [Bash] [Edit] [Write] [Agent] * feat(website): add a star history chart, rewrite the history post in first person The history post read like a changelog written by a committee. It is now in Ettore's voice, first person, with the admissions left in. The numbers paragraph in particular read like a directory listing. It now says what the figures mean rather than which file they came from. Adds an interactive star history chart, built from the GitHub stargazers API rather than embedded from a third party, so the page makes no external request and cannot break when someone else's service is down. The four releases the post is organised around are marked on the curve, and the labels stack into rows because three of them land within two months of each other. The API stops paginating at 40,000 items, so the curve is measured up to December 2025 and the segment from there to today's total is drawn dashed, labelled as an estimate in the caption and in the tooltip. It is a straight line between two known points, and the chart says so rather than implying it is data. Also drops "marketing site" from the README heading and everywhere else it appeared, and calls it the main site instead. Signed-off-by: Ettore Di Giacinto <mudler@localai.io> Assisted-by: Claude Code:claude-opus-5 [Bash] [Edit] [Write] --------- Signed-off-by: Ettore Di Giacinto <mudler@localai.io> Co-authored-by: Ettore Di Giacinto <mudler@localai.io>
2.5 KiB
2.5 KiB
Preparing a Release
A release is not finished when the tag is pushed. The GitHub release, the blog post and the demo clips ship together, because the changelog says what moved and the post and the clips are what make anyone care.
What a release must include
- Labels on the merged PRs. GitHub generates the raw notes from PR labels, so label first, generate second. Wrong labels mean a miscategorised changelog that has to be edited by hand.
RELEASE_NOTES_vX.Y.Z.mdat the repository root, in the house style: what changed, why it matters, PR numbers so people can read the diffs.- A blog post under
website/content/blog/. One post per release, front matter withtitle,date,author,category: "Release",tags,summaryandextracss: ["blog.css"]. Cover the two or three changes that alter what a user does day to day, not the whole changelog, and link the PR numbers. Seewebsite/content/blog/what-landed-in-localai-4-8.mdfor the shape. - Demo clips for the notable features. Anything visible (a new backend, a UI change, a new endpoint, a measured speedup) gets a short screen recording. Put the file in
website/static/media/, reference it from the blog post, and reuse it on the marketing pages where it fits.
A release without a post and without clips is incomplete, in the same way a user-facing code change without a docs update is incomplete.
Clip conventions
- MP4, H.264, no audio track unless the feature is about audio. Keep them short (10 to 30 seconds) and loopable.
- Record the real thing. A clip from the engine's own benchmark suite or a real session, never a mockup.
- Where the change is a speedup, record both sides on the same machine on the same input, so the comparison is honest.
- Name the file after the feature, not the release (
vllm-race.mp4, notv4-8-demo.mp4), so it stays reusable once the release is old. - The marketing site plays clips with
muted loop playsinline preload="none"and adata-lazyattribute, which the site's IntersectionObserver uses to play and pause them on scroll. Follow that pattern for anything you add.
Order of work
Label the PRs, generate and edit the release notes, cut the draft release, record the clips while the branch is still fresh in your head, then write the post against the notes and the clips. Publishing the release and merging the post should happen on the same day.
The creating-localai-releases skill drives steps 1 to 3 and captures the React UI screenshots that go into the notes.