Potential Maintenance Challenges with Locked mkdocs-material Version

[PierreDillard]

Description:
The current setup locks the site to mkdocs-material version 9.5.44, implemented to prevent layout issues during automatic deployments after each commit to the master branch. While this solution is effective for now, it may lead to maintenance challenges in the future as mkdocs-material evolves.

Background:

• Recent modifications in base.html directly impact the foundational files of mkdocs-material, including CSS and JavaScript, which are hashed and minified during each release.
• Since mkdocs-material’s release process can alter file hashes, the current configuration may require manual updates to these references in the future.

[nlsdvl]

@PierreDillard - Locking the version is required not just for deployment, but also for any fresh local dev installation.

Indeed, the challenge comes from the modifications made to base.html.

Ways to deal with this situation include forking of mkdocs-material, or refactoring to avoid making changes to base.html.

Whenever updating the base.html file, the mkdocs-material version from which is was taken must be reflected in the README.md and in the automatic deployment workflow.

[PierreDillard]

Small update on this topic:

Material for MkDocs is officially in maintenance mode:
mkdocs-material/issues/8523

There is also an official Material blog post explaining the broader issue around MkDocs 2.0 and the risk of backward-incompatible changes for existing MkDocs projects:
What MkDocs 2.0 means for your documentation projects

For our wiki, I don’t think this is an immediate blocker (mkdocs-material is locked to 9.5.44).
But I think we should treat this as a maintenance signal.

[rbouqueau]

Thanks. Has anyone tried the migration locally to see what work is actually needed?