From d479b486af41c43abb62dbf8c39f27327112342a Mon Sep 17 00:00:00 2001 From: h-east Date: Sun, 7 Sep 2025 12:31:54 +0900 Subject: [PATCH 1/2] Update develop.{txt,jax} --- doc/develop.jax | 28 +++++++++++++++++++++++++++- en/develop.txt | 34 +++++++++++++++++++++++++++++++++- 2 files changed, 60 insertions(+), 2 deletions(-) diff --git a/doc/develop.jax b/doc/develop.jax index 3b837cac0..a4f891419 100644 --- a/doc/develop.jax +++ b/doc/develop.jax @@ -1,4 +1,4 @@ -*develop.txt* For Vim バージョン 9.1. Last change: 2025 Sep 01 +*develop.txt* For Vim バージョン 9.1. Last change: 2025 Sep 04 VIMリファレンスマニュアル by Bram Moolenaar @@ -12,6 +12,7 @@ Vimの開発 *development* 2. 決定事項 |design-decisions| 3. 想定していること |design-assumptions| 4. コーディングスタイル |coding-style| +5. ポリシー |design-policy| ソースコードの概要については "src" ディレクトリのREADME.txtを見てください。 @@ -725,5 +726,30 @@ OK: do while (cond); +============================================================================== +5. ポリシー *design-policy* *new-features* *deprecated-features* + +新しいマイナーバージョン (例えば 9.2.0) またはメジャーバージョン (例えば 10.0) +がリリースされるまでの期間を開発サイクルと呼ぶ。開発サイクルでは、C コアへの変 +更ごとに、特定のパッチリリースを参照できるように、人間が判読できる新しいパッチ +番号が付与される。典型的な開発リリースサイクルは数年続き、約 1500 ～ 2500 個の +パッチ番号が蓄積される。 + +リリース前に安定期間が告知される。この期間中は、明確なバグ修正、セキュリティ修 +正、ドキュメントの変更、翻訳の更新、ランタイムファイルの更新 (後方互換性を損な +う変更を含まないこと) のみを受け付け、次期リリースの完成度を高めることに集中す +る。 + +新機能は開発サイクル内でのみ承認され、安定期間中は承認されない。サイクル中は新 +機能の開発と変更が許可されるが、サイクル終了前に確定する必要がある。 + +マイナーリリースが作成されると、そのリリースに含まれる機能には後方互換性のない +変更は一切加えられなくなる。その後のパッチでは、Vim の C コアの互換性が維持さ +れることが期待される。ランタイムファイルは、ランタイムファイルのメンテナーが古 +い動作を変更できるように、より柔軟に扱われる。 + +開発サイクル中に、機能が非推奨としてマークされる場合がある。非推奨機能は、コン +パイル時に適切なスイッチを使用して無効化できる。新しいリリースの後、非推奨機能 +は次のサイクルで完全に削除される可能性がある。 vim:tw=78:ts=8:noet:ft=help:norl: diff --git a/en/develop.txt b/en/develop.txt index 2d486b6ba..50d9b04f6 100644 --- a/en/develop.txt +++ b/en/develop.txt @@ -1,4 +1,4 @@ -*develop.txt* For Vim version 9.1. Last change: 2025 Sep 01 +*develop.txt* For Vim version 9.1. Last change: 2025 Sep 04 VIM REFERENCE MANUAL by Bram Moolenaar @@ -13,6 +13,7 @@ Vim. 2. Design decisions |design-decisions| 3. Assumptions |design-assumptions| 4. Coding style |coding-style| +5. Policy |design-policy| See the file README.txt in the "src" directory for an overview of the source code. @@ -728,4 +729,35 @@ OK: do while (cond); +============================================================================== +5. Policy *design-policy* *new-features* *deprecated-features* + +The time between either a new minor (e.g. 9.2.0) or major (e.g. 10.0) version +is released is called a development cycle. Within the development cycle each +single change to the C core will receive a new increased human-readable patch +number in order to reference each specific patch release. A typical +development release cycle may last several years and accumulate about 1500 - +2500 patch numbers. + +Before a release is made, a stability period will be announced. During this +time, only clear bug fixes, security fixes, documentation changes, translation +updates and runtime file updates will be accepted (provided they do not +introduce backwards-incompatible changes), concentrating on polishing up the +upcoming release. + +New features are accepted only within a development cycle, but not within the +stability period. During the cycle, new features may be developed and are +allowed to change, but they must be settled before the cycle closes. + +Once a minor release has been made, features included in that release must not +receive any backwards-incompatible changes. Later patches are expected to +preserve compatibility for the C core of Vim. Runtime files are handled a bit +more flexibly to give runtime files maintainers a chance to change old +behaviour. + +Within a development cycle, features may be marked as deprecated. Deprecated +features can be disabled at compile time through an appropriate switch. After +a new release, deprecated features may be removed completely in a following +cycle. + vim:tw=78:ts=8:noet:ft=help:norl: From 6820a1f7882f9639ddf43a074dca949c245b0ed3 Mon Sep 17 00:00:00 2001 From: h-east Date: Wed, 10 Sep 2025 22:18:13 +0900 Subject: [PATCH 2/2] Update by original --- doc/develop.jax | 2 +- en/develop.txt | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/develop.jax b/doc/develop.jax index a4f891419..287c7c4b6 100644 --- a/doc/develop.jax +++ b/doc/develop.jax @@ -1,4 +1,4 @@ -*develop.txt* For Vim バージョン 9.1. Last change: 2025 Sep 04 +*develop.txt* For Vim バージョン 9.1. Last change: 2025 Sep 07 VIMリファレンスマニュアル by Bram Moolenaar diff --git a/en/develop.txt b/en/develop.txt index 50d9b04f6..70176f831 100644 --- a/en/develop.txt +++ b/en/develop.txt @@ -1,4 +1,4 @@ -*develop.txt* For Vim version 9.1. Last change: 2025 Sep 04 +*develop.txt* For Vim version 9.1. Last change: 2025 Sep 07 VIM REFERENCE MANUAL by Bram Moolenaar @@ -448,13 +448,13 @@ For everything else use: > INDENTATION *style-indentation* -We use 4 space to indent the code. If you are using Vim to edit the source, +We use 4 space to indent the code. If you are using Vim to edit the source, you don't need to do anything due to the |modeline|. For other editors an `.editorconfig` is provided at the root of the repo. For the source files `sign.c` and `sound.c` and any new file use only spaces, -no tabs. In addition, any new file must include a modeline with `set et` to +no tabs. In addition, any new file must include a modeline with `set et` to pass the indentation test. @@ -539,7 +539,7 @@ Wrong: > TYPES *style-types* -Use descriptive types. These are defined in src/vim.h, src/structs.h etc. +Use descriptive types. These are defined in src/vim.h, src/structs.h etc. Note that all custom types are postfixed with "_T" Example: > @@ -739,7 +739,7 @@ number in order to reference each specific patch release. A typical development release cycle may last several years and accumulate about 1500 - 2500 patch numbers. -Before a release is made, a stability period will be announced. During this +Before a release is made, a stability period will be announced. During this time, only clear bug fixes, security fixes, documentation changes, translation updates and runtime file updates will be accepted (provided they do not introduce backwards-incompatible changes), concentrating on polishing up the @@ -755,8 +755,8 @@ preserve compatibility for the C core of Vim. Runtime files are handled a bit more flexibly to give runtime files maintainers a chance to change old behaviour. -Within a development cycle, features may be marked as deprecated. Deprecated -features can be disabled at compile time through an appropriate switch. After +Within a development cycle, features may be marked as deprecated. Deprecated +features can be disabled at compile time through an appropriate switch. After a new release, deprecated features may be removed completely in a following cycle.