Files

kid aa92d0e676 初始提交：terminalX 可运行态（M0/M1/M1.5 已真机验证）

- M0: libghostty SSH 终端（渲染/输入/连接）+ 白屏修复(OutputGate) + 会话状态机/自动重连
- M1: tsnet 用户态组网 + SSH-over-tsnet(fd 桥)，shell 级真机验证；R5(Go+gvisor+C+++Swift 同进程) retire
- M1.5: tmux -CC 原生 tab（MVP）
- 结构: packages/(TXCore·TXTransport), apps/TerminalX, vendor/(libghostty-spm/libssh2/mbedtls/tsnet-bridge), artifacts/
- 文档: CLAUDE.md + docs/HANDOFF.md（新会话入口）
- 环境: 认证代理→依赖 vendor 本地化；Go 在 ~/.local/go；仅模拟器/未签名
- 待续: M2 mosh, tmux 多 pane, M4 安全(host key/SE)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-24 10:20:46 +08:00

3.3 KiB

Raw Blame History

Pending changelog entry directory

This directory contains changelog entries that have not yet been merged to the changelog file (../ChangeLog).

What requires a changelog entry?

Write a changelog entry if there is a user-visible change. This includes:

Bug fixes in the library or in sample programs: fixing a security hole, fixing broken behavior, fixing the build in some configuration or on some platform, etc.
New features in the library, new sample programs, or new platform support.
Changes in existing behavior. These should be rare. Changes in features that are documented as experimental may or may not be announced, depending on the extent of the change and how widely we expect the feature to be used.

We generally don't include changelog entries for:

Documentation improvements.
Performance improvements, unless they are particularly significant.
Changes to parts of the code base that users don't interact with directly, such as test code and test data.
Fixes for compiler warnings. Releases typically contain a number of fixes of this kind, so we will only mention them in the Changelog if they are particularly significant.

Until Mbed TLS 2.24.0, we required changelog entries in more cases. Looking at older changelog entries is good practice for how to write a changelog entry, but not for deciding whether to write one.

Changelog entry file format

A changelog entry file must have the extension *.txt and must have the following format:

Security
   * Change description.
   * Another change description.

Features
   * Yet another change description. This is a long change description that
     spans multiple lines.
   * Yet again another change description.

The permitted changelog entry categories are as follows:

API changes
Default behavior changes
Requirement changes
New deprecations
Removals
Features
Security
Bugfix
Changes

Use “Changes” for anything that doesn't fit in the other categories.

How to write a changelog entry

Each entry starts with three spaces, an asterisk and a space. Continuation lines start with 5 spaces. Lines wrap at 79 characters.

Write full English sentences with proper capitalization and punctuation. Use the present tense. Use the imperative where applicable. For example: “Fix a bug in mbedtls_xxx() ….”

Include GitHub issue numbers where relevant. Use the format “#1234” for an Mbed TLS issue. Add other external references such as CVE numbers where applicable.

Credit bug reporters where applicable.

Explain why, not how. Remember that the audience is the users of the library, not its developers. In particular, for a bug fix, explain the consequences of the bug, not how the bug was fixed. For a new feature, explain why one might be interested in the feature. For an API change or a deprecation, explain how to update existing applications.

See existing entries for examples.

How `ChangeLog` is updated

Run [../framework/scripts/assemble_changelog.py] (../framework/scripts/assemble_changelog.py) from a Git working copy to move the entries from files in ChangeLog.d to the main ChangeLog file.

3.3 KiB Raw Blame History