Skip to content

Update develop.{txt,jax} #2297

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 12, 2025
Merged

Update develop.{txt,jax} #2297

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d479b48
Update develop.{txt,jax}
h-east Sep 7, 2025
6820a1f
Update by original
h-east Sep 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 27 additions & 1 deletion doc/develop.jax
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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 07


VIMリファレンスマニュアル by Bram Moolenaar
Expand All @@ -12,6 +12,7 @@ Vimの開発 *development*
2. 決定事項 |design-decisions|
3. 想定していること |design-assumptions|
4. コーディングスタイル |coding-style|
5. ポリシー |design-policy|

ソースコードの概要については "src" ディレクトリのREADME.txtを見てください。

Expand Down Expand Up @@ -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:
40 changes: 36 additions & 4 deletions en/develop.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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 07


VIM REFERENCE MANUAL by Bram Moolenaar
Expand All @@ -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.
Expand Down Expand Up @@ -447,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.


Expand Down Expand Up @@ -538,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: >
Expand Down Expand Up @@ -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: