diff --git a/doc/develop.jax b/doc/develop.jax
index 3b837cac0..287c7c4b6 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 07
 
 
 		  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..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 01
+*develop.txt*   For Vim version 9.1.  Last change: 2025 Sep 07
 
 
 		  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.
@@ -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.
 
 
@@ -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: >
@@ -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: