On Mon, Feb 16, 2026 at 05:27:00PM +0100, Evgeny Kotkov via dev wrote:
> Hi all,
>
> During the recent discussion about releasing Subversion 1.15, several issues
> with our current LTS/regular release policy [1] were highlighted [2].
>
> Building on Brane's suggestion, Nathan and I have drafted a definition for an
> updated release policy to resolve the issues. Namely, it should:
>
> - Encourage packagers to pick up new releases, instead of postponing adoption
> until the next LTS release.
> - Address the problem that we might not have enough resources for a steady
> rate of non-empty regular releases every 6 months.
> - Allow us to not have to decide whether 1.15 should be a regular or an LTS
> release, given that both of them have downsides after a long break in our
> release cycle.
> - Return us to a proven model that worked well in the past.
>
> The policy is defined as follows:
> -----------------------------------------------------------------------------
>
> Starting with 1.15, all release lines are supported for at least 3 years.
> At least one release line is always supported.
>
> A release line becomes EOL when the following conditions are met
> simultaneously:
> - It has been supported for at least 3 years.
> - There is a new minor release line with an age of at least 3 months.
>
> Among the supported release lines:
> - The latest release line ("N") receives full support.
> - Other release lines (N-1, N-2, …) receive security-only support and
> critical bugfixes, e.g., related to data corruption.
>
> -----------------------------------------------------------------------------
>
> While I believe there's rough consensus about it, I want to make sure this
> change receives appropriate attention.
>
> Personally, I am +1 to moving forward with this policy for 1.15 and later
> releases.
+1 from me. I welcome this change. This is long overdue from my point of view.
For several years our currently documented release policy has not been
followed in practice. The suggested new approach matches current reality
much better.
Regards,
Stefan
