Make download links dynamic

[maxwxyz]

New feature or enhancement

Feature topic

Pick appropriate topics:

• Download

Feature summary and motivation

Weekly download assets change every week, stable assets will be released more often in the future. This change will create the download links dynamically.

Bildschirmaufnahme.2026-07-17.um.21.35.56.mov

Changes description and implementation

• Dynamically resolve the latest stable FreeCAD release and its OS pecific download assets from the GitHub Releases API
• Keep stable download links independent of release tag naming changes
• Add a collapsible Download Latest Weekly section with a development-build warning
• Resolve the newest dated Weekly prerelease separately
• Keep GitHub Releases links as a no-JavaScript fallback and hide unavailable assets safely
• Made all titles Title Case on the download page as well
• Assisted by: GPT-5.6

Related issues

PR checklist

• This change is verified to work as described. The documentation is added/updated if necessary.
• This change complies with the repository Guidelines.

[github-actions]

PR #48 preview:

https://FreeCAD.github.io/Website/pr-48/

[marcuspollio]

Hi @maxwxyz
Thanks for your contribution!

Yeah, improving the resolution of builds data and links is definitively needed, specially with the increased release schedule.
I suppose you read the discussion on this issue, correct?

Some comments regarding the overall design:

1. Where to place development builds info and links? In your PR, users click the red button (i.e. fake card) and the collapsed section with dev builds is shown with a layout a bit similar to the stable one on the top hero. While it works, I am sure we find a nicer and clearer design, that can also evolve better in the future, as we add or change download info, assets, and workflow. What about having a dedicated "weekly builds"/"development builds"/"unstable/"experimental"/whatever page, in place of the builds one (currently just links to GitHub releases), with the latest builds on the top hero (similar layout than your red section or the stable one on normal download page), and then below a list of "historical builds", akin to what @mnesarco proposed here?

2. The same workflow (i.e. more automatic builds data and links resolution) improvements should also be applied to the individual release notes pages, as they also allow to download release-specific assets/builds.

3. Later on, we can add nice quality-of-life info and features like assets filesize, hash utilities, etc. I propose we do them in a later PR, but let's just keep them in mind as we refine the design here, so it's easier to implement later.

Regarding the implementation, here are the main concerns:

4. There are severe flaws in this PR that must be changed: from the start of this website project implementation, I have tried to keep two core paradigms: separation of concerns and progressive enhancement. In the website case, the first means that data, assets, or content is sourced in a well-defined and separate manner/workflow (e.g. mount content/assets, resolve remove resources, get remove data, etc), then as a subsequent and separate step the website is built/generated (website theme and templates, either locally via CLI or via CI workflows). The second paradigm means that all essential functionalities must work reliably and (almost) the same for all users (whatever their systems or peculiarities), and that it's OK only for minor features/QoL to not work for a subset of users. In short, using JS to get and display downloads (one of the very main points of having the website in the first place) and some odd technical fallback (i.e. "If JavaScript is unavailable..."), is not OK.

5. The "turn-a-card-into-a-button-that-shows-a-hidden-section" feels like a hack. See my recommendations below.

6. Many custom params are added. While being explicit is good, they can probably all be avoided if existing partial logic is used and tweaked instead. We should also avoid hard-coding custom values in general templates (e.g. list.html, main/card.html), as it lowers the theme flexibility and general-purpose scope.

7. I am not convinced we should split the custom download partial even more. Passing the context into the partial should normally allows for different logic without too much duplication.

8. This PR is missing one opportunity I really want to see resolved with this "automatic" workflow: the ugly and too-complex download fields currently scattered in config/_default/params.yaml and content/en/download/releases/<tag>/index.md params. These should be removed or just keep few minimal ones, in favor of the more complete JSON data.

9. As a multi-lingual site, all strings must be translatable, either via content (fields and body) or i18n tables.

So, to move forward in actionable steps, I would recommend:

• Have a look at @mnesarco Python code in order to add a new "releases" workflow (or any other name) that generates a simple /data/releases.json. The script can be placed in /tools/workflows/releases.py (please also document its use in /tools/README.md). A simple /.github/workflows/releases.yaml CI action can be added (maybe a weekly CRON just after the wednesday builds is enough?).
• Adapt the custom download partial to make use of this JSON data, with some simple context-based logic to separate between the latest stable for the top hero on the download page, specific releases pages (e.g. 1.1 release notes page gets latest 1.1.1, 1.0 notes gets 1.0.2, etc), and the latest dev builds for "weeklies/"experimental"/whatever page. A second custom partial can be designed for the "historical builds" if wanted. This way, the "red" card to weeklies keeps its meaning (i.e. a card that links to another page) and is not faked into a hybrid and inconsistent feature.
• Tweak the rest (text, style, custom info, etc) and add other cool features (some of them can be enhancements via JS if needed)

One or several PRs are OK, up to you, try to group related changes by commits.
How does that sound? Feel free to ask clarifications.
TIA, have a good one!

[maxwxyz]

I didn't know about the linked issue.

1. This was just a proposal / POC. I also would like to see a better design, but it needs to be not directly at the top as we do not want any accidental dev version downloads when people are looking for the stable one. I'd still prefer the direct link to the latest weekly artefacts as in @mnesarco issue described. One link at the end to the entire releass or all "stable" builds is fine (additionally). Idealy we also just present the artifact for the OS of the user (like Blender does).
2. True but I still hope the documentation will move away from the wiki as with much more releases the differences in functions per command will be difficult to display.
3. agreed

I'm fine if you or @mnesarco pick it up, I wasn't aware of the work in that issue. Feel free to close this POC.

[marcuspollio]

Hi @maxwxyz

Yeah, no worries, prototypes are very much needed!

1. Next we can implement "the real thing" (i.e. robust code, no hacks) gradually, and iterate to improve the design.

2. Indeed, we will certainly move from the wiki to this same base at some point, but that is a bigger endeavor that needs a small team. What do you mean by "the differences in functions per command will be difficult to display"?

I'm fine if you or @mnesarco pick it up, I wasn't aware of the work in that issue. Feel free to close this POC.

So, you do not want to continue these changes for now? I can help (guidance and code) if you still want to give it a try. 😉