Author: dsahlberg
Date: Mon Feb 23 20:12:46 2026
New Revision: 1932015
Log:
In site/publish: Merge r1931988, r1931998 and r1931999 from trunk.
Document new release policy as discussed on dev@:
https://lists.apache.org/thread/gwkrrmg3qh01zmlb1wvt5vp0r5k9rsrn
* roadmap.html
(#release-planning): Rename to #support-period and describe
the release policy.
* docs/community-guide/releasing.part.html
(#release-stabilization-how-many-votes): Remove number of votes required for
backports to regular releases, since we don't use that type of release
anymore.
(#releasing-announce): Remove the detailed instructions about which backport
branches usually are supported, since the new release policy may have none
or many currently supported releases.
Modified:
subversion/site/publish/ (props changed)
subversion/site/publish/docs/community-guide/releasing.part.html
subversion/site/publish/roadmap.html (contents, props changed)
Modified: subversion/site/publish/docs/community-guide/releasing.part.html
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html Mon Feb 23 20:10:02 2026 (r1932014)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Mon Feb 23 20:12:46 2026 (r1932015)
@@ -678,15 +678,10 @@ it.</p>
title="Link to this section">¶</a>
</h4>
-<p>For a <b>non-LTS ("regular") release line</b>,
-a change is approved if it receives <b>two +1s</b> and no vetoes. (Only
+<p>A change is approved if it receives <b>three +1s</b> and no vetoes. (Only
binding votes count; see above.)</p>
-<p>For an <b>LTS release line</b>,
-a change is approved if it receives <b>three +1s</b> and no vetoes. (Only
-binding votes count; see above.)</p>
-
-<p>Notwithstanding the above, for any release line, a change that
+<p>A change that
affects only areas that are <b>not core code</b> (for example,
tools/, packages/, bindings/, test scripts, etc.),
and that does <b>not affect the build system</b>,
@@ -1422,9 +1417,7 @@ be contacted via the announce-owner@ han
<p>If this is an X.Y.0 release, update the community support level at the very
top of the <tt>STATUS</tt> files of any branches that have changed support
-status. This would usually be <tt>X.Y.x/STATUS</tt>,
-<tt>X.$((Y-1)).x/STATUS</tt>, and if the new release is an LTS release, then
-the oldest supported LTS branch's <tt>STATUS</tt> file as well.</p>
+status.</p>
</div> <!-- releasing-announce -->
Modified: subversion/site/publish/roadmap.html
==============================================================================
--- subversion/site/publish/roadmap.html Mon Feb 23 20:10:02 2026 (r1932014)
+++ subversion/site/publish/roadmap.html Mon Feb 23 20:12:46 2026 (r1932015)
@@ -75,70 +75,38 @@
</div> <!-- #upcoming-releases -->
-<div class="h2" id="release-planning">
-<h2>How We Plan Releases
- <a class="sectionlink" href="#release-planning"
+<div class="h2" id="support-period">
+<h2>Release support period
+ <a class="sectionlink" href="#support-period"
title="Link to this section">¶</a>
</h2>
-<p>Subversion has two types of releases:
- <em>regular</em> releases are intended to deliver new features more quickly, while
- <em><acronym title='Long-Term Support'>LTS</acronym></em> releases are intended to provide stability over longer periods.
-</p>
+<p>Starting with 1.15, all release lines are supported for at least 3 years.
+ At least one release line is always supported.</p>
-<p>The two types releases differ in their support lifetime:</p>
+<p>A release line becomes EOL when the following conditions are both met:</p>
<ul>
+<li><p>It has been supported for at least 3 years.</p></li>
+<li><p>There is a new minor release line with an age of at least 6 months.</p>
+</li>
+</ul>
-<li><p>Regular releases are supported for <b>six months</b> from the date of
-their initial release. For instance, 1.11.x was supported until six months
-after the announcement of 1.11.0. A regular release may be used to get new
-features out sooner without having to support a particular release for an
-extended period of time, to make feature development more appealing, rewarding
-and faster for both the contributors and the users.</p></li>
-
-<li><p>LTS releases are supported for <b>four years</b> from the date of their
-initial release. For instance, 1.14.x will be supported until four years after
-the announcement of 1.14.0.</p>
-
-<p>LTS releases are supported until <b>three months</b> after the release of
-the next LTS.</p>
-
-<p>The previous two guarantees cumulate: for an LTS release line to be declared
-end-of-life (EOL), it has to <em>both</em> have been first released over four
-years before <em>and</em> have been supported in parallel to a newer LTS
-release line for at least three months.</p>
-
-<p>For instance, assume 1.42.0 is released on 2042-07-01 and 1.42 is declared
-an LTS line. In this case, 1.42 will be supported at least until 2046-06-30
-(with no ifs, buts, or maybes). Furthermore, it is expected that a newer LTS
-release (1.43.0, 1.44.0, etc.) will be made before 2046-04-01, leaving three
-months for upgrading installations. In case no newer LTS release is made
-until, say, 2048-01-01, the lifetime of 1.42 will automatically be extended
-until 2048-03-31.</p>
-
-<p>At any given time there will be at least one supported LTS release. The
-most current LTS release will be supported with general backports and any
-older release(s) will receive high priority fixes.</p></li>
+<p>Among the supported release lines:</p>
+<ul>
+<li><p>The latest release line ("N") receives full support.</p></li>
+<li><p>Other release lines (N-1, N-2, …) receive security-only support and
+critical bugfixes, e.g., related to data corruption.</p></li>
</ul>
-<p>During the support period, we commit to providing updates that fix high
-priority issues such as security and data loss or corruption. We may also
-sometimes fix other issues as appropriate to the emphasis of each release.</p>
-
-<p>In this context, "release" means an increment of the minor release
-number, which is the middle number in our three-component system.
-Thus, 1.2.0, 1.3.0, and 1.4.0 are successive minor releases in the
-"1.x" line, whereas 1.1.1, 1.1.2, and 1.1.3 are successive patch
-(bugfix) releases in the "1.1.x" line. We don't schedule patch
-releases far in advance, we just put them out when we feel enough
-bugfixes have accumulated to warrant it. Major new releases, such as
-Subversion 2.0, will probably be done much like the minor releases,
-just with more planning around the exact features.<p>
+<p>Previously Subversion differentiated between <em>regular</em> releases
+(supported for 6 months) and <em><acronym title='Long-Term Support'
+>LTS</acronym></em> releases intended to provide stability over longer
+periods (supported for 4 years).</p>
-<p>To date, every release since 1.0 has been LTS, with the exception of 1.11,
-1.12, and 1.13 which were regular.</p>
+<p>Subversion 1.0 until 1.10 and 1.14 were LTS releases and 1.11, 1.12 and
+1.13 were regular.</p>
<p>For more information about Subversion's release numbering and
compatibility policies, see the section entitled
@@ -146,7 +114,7 @@ compatibility policies, see the section
numbering, compatibility, and deprecation"</a> in the
<a href="/docs/community-guide/">Subversion Community Guide</a>.</p>
-</div> <!-- #release-planning -->
+</div> <!-- #support-period -->
<div class="h2" id="features-most-wanted">
<h2>Our "Most Wanted" Features
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.