Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

docs: versioned docs per release (/vX.Y/, /latest/, /dev/)

未关闭
#1,272 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
文档
描述清晰度
描述清楚
活跃度
活跃
技术栈
c, shell

调研方向

The docs are in the docs/ directory; the release workflow and build system need changes to publish per-version docs. Start by examining the existing documentation build script (likely a shell script or Makefile) and the GitHub Actions workflow for releases. Understand how the current site is deployed. The goal is to create a structure where each release tag's docs are published under /vX.Y/, /latest/ points to the newest release, and main's docs go to /dev/. This involves versioning the docs, adding version markers to pages, and ensuring old versions remain accessible.

由索引模型根据 Issue 内容生成。

描述

area:docs help wanted kind:decision

Problem. The docs site is built from main only. A user on the latest release (v0.43.0) reads docs for whatever is on main, which can describe features, flags or semantics their binary does not have.

What mature languages do. docs.python.org/3.12/, docs.rs//, and pkg.go.dev's version tab all serve each release's docs, with a stable "latest".

Bar.

  1. Each release tag's docs/ is published under /v<major.minor>/, and /latest/ points at the newest release. main's docs are published under /dev/ (or equivalent), clearly labelled unreleased.
  2. Every page carries a visible version marker, with a link to the same page in other versions where it exists.
  3. The release-cut workflow publishes the new version's docs, and the playground is built from the same tag.
  4. Old versions keep working after a new release (a link check against at least the previous version).

Ranked #5 of the docs follow-ups (2026-09-22 comparison with other languages). Most work; matters most once there are outside users.

主要语言
C
星标
3
派生
7
平均合并
4 小时 15 分钟
30 天内合并 PR
106

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

InauguralSystems/EigenScript 的其他 Issue

查看 InauguralSystems/EigenScript 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。