adam/vim
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

runtime(doc): Add a Development policy

Browse Source 
closes: #18197

Signed-off-by: Christian Brabandt <cb@256bit.org>
This commit is contained in:
Christian Brabandt
2025-09-04 21:56:08 +02:00
parent b2e21cccc7
commit 6d8307fc2f
3 changed files with 37 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
runtime/doc/develop.txt
View File

@ -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: