More intuitive branch names for documentation versions on Read the Docs ?

[unman]

Issue #10251 relates to branch names for documentation versions on Read the Docs

I'd like to bring this to a close with agreement.

The default names on RTD are "latest" to track main branch, and
"stable" to track the highest versioned branch.

There are arguments in favour of changing this. For what it's worth,
most RTD projects seem to use the default; Fedora uses "latest" for
the most recent release; Debian uses "stable" for the most recent
release, (and "oldstable" for the one before.)

These projects do not seem to see any issue with using these names in
their documentation, instead of URLS that point to specific releases,
(although they may support that also).

I do not know if it's possible to change the default namings in RTD to
keep the automatic updating. The documentation isnt particularly clear
on this, and (ironically) the documentation on building a working local
RTD on Debian is woeful.

It IS possible to change the default view to show documentation for the
stable branch. We should do this, under whatever name is chosen.

I think we need to establish:
1. Is it possible to change the default names - latest and stable?
2. If so, what names should we use?
3. If we do, is it possible to retain automatic generation of docs for
the most recent versioned branch?
4. If we do change from defaults, and it is not possible to retain
automatic generation, can we manually set our choice to point to the
most recent versioned branch?

2 is for general discussion.
1,3,4 need input from folk familiar with RTD.

unman

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Oct 10, 2025 at 01:16:16PM +0100, 'unman' via qubes-devel wrote:
> Issue #10251 relates to branch names for documentation versions on Read the Docs
>
> I'd like to bring this to a close with agreement.
>
> The default names on RTD are "latest" to track main branch, and
> "stable" to track the highest versioned branch.
>
> There are arguments in favour of changing this. For what it's worth,
> most RTD projects seem to use the default; Fedora uses "latest" for
> the most recent release; Debian uses "stable" for the most recent
> release, (and "oldstable" for the one before.)
>
> These projects do not seem to see any issue with using these names in
> their documentation, instead of URLS that point to specific releases,
> (although they may support that also).
>
> I do not know if it's possible to change the default namings in RTD to
> keep the automatic updating. The documentation isnt particularly clear
> on this, and (ironically) the documentation on building a working local
> RTD on Debian is woeful.
>
> It IS possible to change the default view to show documentation for the
> stable branch. We should do this, under whatever name is chosen.
>
> I think we need to establish:
> 1. Is it possible to change the default names - latest and stable?

In practice we can choose any names. The automatically updated "stable"
name is I think hardcoded, but IMO we don't need to use this mechanism -
it's not much work to switch branch every 2 years or so when new qubes
version gets released.

> 2. If so, what names should we use?

This is a very good question. To recap the issue, we have the following
proposals:
1. "latest" for development version, "stable" for most recent stable
version, "4.2" etc for older versions
2. "testing" for development version, "latest" for most recent stable
version, "4.2" etc for older versions
3. always use specific version like "4.2", "4.3"
4. some mix of the above

Unfortunately, version aliases seems to be not implemented yet
(https://github.com/readthedocs/readthedocs.org/issues/5318), so one
branch can have only a single version (it's impossible to have 4.2
visible as both "4.2" and "stable" at the same time).

Personally, I like 1 or 2. And include which version that actually is in
the documentation title (or somewhere else that is always visible).

> 3. If we do, is it possible to retain automatic generation of docs for
> the most recent versioned branch?

It's possible to add automation rules to set default version:
https://docs.readthedocs.io/page/guides/automation-rules.html

But as said above, we don't do new Qubes OS releases that often, it's
IMO okay to simply switch default manually as part of release checklist.

> 4. If we do change from defaults, and it is not possible to retain
> automatic generation, can we manually set our choice to point to the
> most recent versioned branch?

We can set any mapping branch -> version.

> 2 is for general discussion.
> 1,3,4 need input from folk familiar with RTD.
>
> unman

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmjpAHAACgkQ24/THMrX
1ywHFwf+MTKpFZfK4h+cUfHsBPIBwI7aFBzg6H3J2kAAHtJRX9cJcqvWcYVScOtc
qMLH08tYFTq5peyRFz3WYaan3raGHAbBX2C0EGc47vzuSFuh/ukMgATMHxwBVMqg
1iM8dzRG2MXqU8o9kb228+8/mDWnUuCTCJWPeIZcIzTQGoiWcXDxO8hOD0oH0DDX
eKvsu7OI0dVAHF+n0bou9bFNdCa+26pn2xVFgltow0j20E91M8WoxU2nu4baOE/P
7hbAAPdS7R6sM7TSvlE97yPjbHBtsSieVfz8GrvDcWaXGVB/5PGm5ACTYgV6kDlI
bvQGic8JZ6SKye6k5Jlo5r43shO05w==
=8wX1
-----END PGP SIGNATURE-----

[unman]

I agree that a manual change would not be great effort, if the automatic
system can be turned off.

.
>
> > 2. If so, what names should we use?
>
> This is a very good question. To recap the issue, we have the following
> proposals:
> 1. "latest" for development version, "stable" for most recent stable
> version, "4.2" etc for older versions
> 2. "testing" for development version, "latest" for most recent stable
> version, "4.2" etc for older versions
> 3. always use specific version like "4.2", "4.3"
> 4. some mix of the above
>
> Unfortunately, version aliases seems to be not implemented yet
> (https://github.com/readthedocs/readthedocs.org/issues/5318), so one
> branch can have only a single version (it's impossible to have 4.2
> visible as both "4.2" and "stable" at the same time).
>
> Personally, I like 1 or 2. And include which version that actually is in
> the documentation title (or somewhere else that is always visible).

There is also:
5. "testing" and "stable"
(if that is not subsumed under your 4.
This is the one I favor.

>
> > 3. If we do, is it possible to retain automatic generation of docs for
> > the most recent versioned branch?
>
> It's possible to add automation rules to set default version:
> https://docs.readthedocs.io/page/guides/automation-rules.html
>
> But as said above, we don't do new Qubes OS releases that often, it's
> IMO okay to simply switch default manually as part of release checklist.

Agreed.

>
> > 4. If we do change from defaults, and it is not possible to retain
> > automatic generation, can we manually set our choice to point to the
> > most recent versioned branch?
>
> We can set any mapping branch -> version.

OK

Thanks for input.

[parulin]

It would be really great to end up with a decision before the release of
Qubes R4.3, in order to have the two versions during the transition phase.

Could the "testing/stable" proposal of unman be a compromise?

On 10/11/25 06:38, 'unman' via qubes-devel wrote:
> There is also:
> 5. "testing" and "stable"
> (if that is not subsumed under your 4.
> This is the one I favor.

If not, using "latest/stable" would be less confusing than
"testing/latest". But anyway, even that last solution is better than the
current state of the docs (only one branch called "latest").

[tokidev]

Am 13.12.25 um 19:34 schrieb 'parulin' via qubes-devel:

> It would be really great to end up with a decision before the release of
> Qubes R4.3, in order to have the two versions during the transition phase.

Thank you for the reminder!

> Could the "testing/stable" proposal of unman be a compromise?
>
> On 10/11/25 06:38, 'unman' via qubes-devel wrote:
>> There is also:
>> 5. "testing" and "stable"
>> (if that is not subsumed under your 4.
>> This is the one I favor.
> If not, using "latest/stable" would be less confusing than "testing/
> latest". But anyway, even that last solution is better than the current
> state of the docs (only one branch called "latest").
>

What about "latest_testing" for the latest testing release and
"latest_stable" for the latest stable release? Older versions with "4.1"
etc.?

Best regards,
tokidev

[parulin]

So, recently the available versions changed, we now have 3 versions:

* latest
* r4.3 (default)
* r4.2

The idea of using "testing", "latest" or "latest_testing" and "stable"
has been abandoned?

[unman]

Yes. This is clearer and in accordance with naming convention elsewhere.
r4.3 is now the default view in RTD. (I still do not like "latest" but
that's a personal matter of little import.)
"latest" and r4.3 will run closely together for some time, but as work
continues to r4.4 or, indeed r5.0, there will be divergence. It would be
useful if developers could explicitly point out cases where work will not
impact r4.3.

[parulin]

On 2/28/26 05:38, 'unman' via qubes-devel wrote:
> Yes. This is clearer and in accordance with naming convention elsewhere.
> r4.3 is now the default view in RTD. (I still do not like "latest" but
> that's a personal matter of little import.)
> "latest" and r4.3 will run closely together for some time, but as work
> continues to r4.4 or, indeed r5.0, there will be divergence. It would be
> useful if developers could explicitly point out cases where work will not
> impact r4.3.

Ok, but right now, if I want to copy-paste a link, I don't have a good
solution:

* If using the default, the /r4.3/ part might become outdated or, worse,
removed.
* If I use the "latest" version, I might provide a link that contains
information about the next release.

The last situation is not so bad, but I thought that we would have had
some kind of "stable" version (and URL), which would have been the
default one...

[unman]

I do not understand how you think things have changed in this respect? As
soon as we adopted different branches for releases, this issue would
arise **regardless** of the naming scheme.

The r4.3 branch will not be removed.

--
I never presume to speak for the Qubes team.
When I comment in the mailing lists I speak for myself.

[parulin]

On 2/28/26 21:59, 'unman' via qubes-devel wrote:
> I do not understand how you think things have changed in this respect? As
> soon as we adopted different branches for releases, this issue would
> arise **regardless** of the naming scheme.

I'm talking about the URL scheme: having a default URL with
.../stable/... always pointing to the latest stable release would have
helped to keep links up-to-date. Anyway, the current solution is not the
one that you, Marek and others were in favor of, so I don't understand
the decision.

> The r4.3 branch will not be removed.

That's nice to hear.

[unman]

On Sun, Mar 01, 2026 at 04:52:47AM -0500, 'parulin' via qubes-devel wrote:
> I'm talking about the URL scheme: having a default URL with .../stable/...
> always pointing to the latest stable release would have helped to keep links
> up-to-date. Anyway, the current solution is not the one that you, Marek and
> others were in favor of, so I don't understand the decision.

A default URL with stable would certainly lead to link rot, and links
pointing at pages no longer containing the material you hope to link
to. I would have thought this was obvious.
Various options were discussed, but there was no consensus. I think this
scheme is clear.

[parulin]

Following this thread and the recent reopening of the issue, see
https://github.com/QubesOS/qubes-issues/issues/10251#issuecomment-5100284984
I took some notes on this discussion.



First idea: replace "latest" and "stable" with "4.2" and "4.3".

Read the docs defaults:

* "latest" track "the most up-to-date development code" ("main")
* "stable" tracks the highest versioned branch (right now 4.3)

Proposal: "stable" could help to keep links up-to-date
Answer: No stable branch to avoid link rot. [not accurate as of July 2026]

Also: "stable" is ambiguous when two releases are supported (i.e.: 4.3
released but 4.2 not yet EOL)




The plan as of September 2025: rename "latest" to "testing", rename
"stable" to "latest" and have "4.2", "4.3"... branches

Counter-proposal: keep RTD defaults and remove old branches

Everyone agrees to use the latest stable release branch as the default
for the docs (but the name could be "4.3")

"less-technical users are probably less likely to upgrade to
cutting-edge versions right away, they may, ironically, have to interact
with the branch selector more than advanced users."

Comparison with other projects:

* most RTD projects use the defaults
* "latest" is the most recent release for Fedora
* Debian uses "stable" for this, "oldstable" for the previous version



List of proposals:

1. "latest" for development version, "stable" for most recent stable

version, "4.2" etc for older versions (RTD defaults)

2. "testing" for development version, "latest" for most recent stable
version, "4.2" etc for older versions
3. always use specific version like "4.2", "4.3"
4. some mix of the above

5. "testing" and "stable"
6. "latest_testing" for the latest testing release and "latest_stable"

for the latest stable release? Older versions with "4.1" etc.

Remark: A branch can't have an alias (i.e: being 4.3 and stable at the
same time) [wrong assertion, see below]

Old branches won't be removed.



In February, we had "latest", "4.3" and "4.2".

Since April (maybe), there is a new branch called "development",
pointing to "main", so on RTD we have:

* "development" tracking the most up to date development code (=
"latest" or "testing" in the previous discussion)
* "latest" tracking the latest stable release (also called "stable" in
previous discussion, this is currently an alias of "r4.3")
* "r4.3", "r4.2"... branches with "r4.3" being the default branch

The sort order is: "latest", "r4.3", "r4.2", "development"

New suggestion pointing inconsistencies with other projects and RTD
defaults: rename "development" to "latest", use "stable" as the default
branch and change the sort order with the latest development branch
being the first.



To me, that's quite clear except why "development" has been chosen over
"testing"?

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

'parulin' via qubes-devel, 2026-07-28 17:33 +02:00:

> Following this thread and the recent reopening of the issue, see
> https://github.com/QubesOS/qubes-issues/issues/10251#issuecomment-5100284984

> [...]

Since this is a response to Ben's comment, let me quote it in full:

> IMHO documenting the branch naming scheme should be a requirement to
> close this issue. Because the issue was discussed on qubes-devel, but
> the final decision was not shared there, and I didn't find a PR that
> set the new names (so it appears to be a build config rather than in
> repository code), and the end result is not an intuitive naming
> scheme:
>
> - `latest` is not the latest

It's the latest released version of Qubes OS. And the version that is in
general recommended to use.

> - `development` name was not discussed and it is very long, could have
> been "testing", the same name we use for unstable releases

I think devel[opment], is pretty common use. See for example our "devel"
repo that also tracks the main git branch.

> Comparison with other projects:
>
> - [Qubes](https://doc.qubes-os.org/en/r4.3/)
> - defaults to `r4.3`, unlike the others
> - developers use `development`, unlike the others that use `latest`
> - names are not chronologically ordered, the branch chooser shows
> as `latest`, `r4.3`, `r4.2`, `development`, but `development`
> should be on the left side of `latest`, like the others.
> - has EOL version for now, but there are plans to remove it
> - [borgbackup](https://borgbackup.readthedocs.io/en/stable/#):
> - defaults to `stable`
> - there are specific versions to choose (they don't remove old versions)
> - developers use `latest`, chronologically sorted
> - has EOL version
> - [Securedrop workstation](https://workstation.securedrop.org/en/stable/):
> - defaults to `stable`
> - developers use `latest`
> - no EOL version
> - [Python](https://docs.python.org/3/)
> - URL defaults to the major stable release `3`
> - branch chooser defaults to the last release, 3.14.6
> - doesn't use branch names, only for `dev` and `pre`
> - has EOL versions
> - [RTD](https://docs.readthedocs.com/platform/stable/):
> - defaults to `stable`
> - other branches are not listed via the branch chooser but if you
> type `latest` in the URL you get the developers version with a
> warning: _This is the latest development version. Some features
> may not yet be available in the published stable version. Read the
> stable version of this documentation._
> - no idea about EOL version, might be hidden
>
> - [RTD - Versions](https://docs.readthedocs.com/platform/latest/versions.html):
>
>> Having a “stable” and “latest” branch so that users can see the
>> current release and the upcoming changes.
>
> We don't have that.
>
> - [RTD - Versions are Git tags and branches](https://docs.readthedocs.com/platform/latest/versions.html#versions-are-git-tags-and-branches)
>
>> Read the Docs also creates a `latest` version that points to the
>> default branch defined in your Git repository (usually `main`). This
>> version should always exist and is the default version for your
>> project.
>
> `lastest` It is the "default version of the project", doesn't mean it
> is the default we should use. It certainly isn't the default RTD uses
> when visiting https://docs.readthedocs.com, it will choose `stable`.
>
> - [RTD - Versioning workflows](https://docs.readthedocs.com/platform/latest/versions.html#versioning-workflows)
>
>> The `latest` version points to the most up to date development code.
>> If you develop on a branch that is different than the default for
>> your version control system, set the **Default Branch** to the branch
>> you use.
>
> I think I have made enough points that:
>
> - replace `development` branch for `latest`
> - point `stable` branch to the last stable release
> - default to `stable` branch

I wasn't involved in deciding what names to use, but to me the current
scheme makes a lot of sense.

What is called "latest", "stable", etc. and what is the default to look
at is very different from project to project (I mean in projects in
general, not RTD specifically). And "latest" in particular is inherently
ambiguous. Is it the latest development version? The latest release? The
latest version of the docs (for which branch?)?

So I think we should pick something that makes sense for our project and
the current scheme does this, in my opinion:

- It defaults to the latest release (what most users want to look at),
with the version number so that links are more stable.
- The list is followed by older versions.
- The "latest" alias allows links that always point to the latest
released version. (A redirect, if supported by RTD, would be nicer
for this)
- development branch listed last, since most users don't want to look
at that version and anybody that needs it, knows enough to understand
the differences.

In your examples the Python example is rather similar. Another very
similar example would be Fedora's user docs:

https://docs.fedoraproject.org/en-US/fedora/latest/

(you might need to scroll in the sidebar after clicking on the version,
to see the full list)

- Default "latest", meaning "latest release".
- Versioned numbers for older releases.
- Special name for development version ("rawhide")

I wouldn't worry so much about what's the default in RTD. From the
person reading the docs, RTD is an implementation detail and their
default doesn't match clearly on Qubes anyway:

- For some duration we have multiple supported releases.
- "stable" is not wrong, but a bit odd naming, since we mostly just
talk about releases, without further categorizing (unlike for example
the Linux kernel)
- "latest" is ambiguous and not what most users want to look at

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmpp1IgACgkQkO9xfO/x
ly+tFQ//QewZbYnnpgCEw+96Yu4jx3hAIUFl0vahwmFQvAtkM9YMj9GTla9jw3Tb
dFqYLFuOZstSNgdQnEKtRohaRP0LhyQs/NV0mJg2CQxL/YAIFMPk1xvtCXKQwdwk
bOs4TMtGoNfeVXkjnlxnqgwindtMj55BuSpsKIjlFTATX/iFqbLeGehTAZfv9CFp
hKxFMy+kyhzR9sp59SWZHvZtWcdJhm4NKW3zkFs79z0Zv6THaZNyAsKz9jtufQYh
hW4dGY2Lt/frufV6CAsb9tIP6g+LJSFeBHxaqMGCaMS9OKK1SCNxGjhH4bmQfuE7
PhWqo6r+ARSrNh+SSWnI279H4xtDTWvmOocL+e9RynF1BYqHmFIDUreeAWgYxFJL
9wsalEbVru6DCxDRMPezLE8qyoGgWpnh1GIcsTkyUpg8T56Ws8wiVDg1HuvxsjZ8
G2kVawcoBUuT5GXjxRt2jUpzVn9uTuEea8igYp0HAJjgxwWf0wu7nNA9hnQatgKa
KUvYogM7RTH0rEZAJ2muUCHV2JaI2S+I6o/RMyr+YoYsDzZtCjiaBQ4tUKcdmIDt
IPMhqyS74LMH1QkcG59a8XK2Gco82gpaRGywQ34NOCMQFQmIxwMhCAVA+a0rEb7h
DVO+dzXu3N4qJ0B3G7Y8O2YLe/FO+ZvdAQxEN9zGH8H7+b6inp4=
=+vE6
-----END PGP SIGNATURE-----

[unman]

> >> Having a ???stable??? and ???latest??? branch so that users can see the

Thanks Simon for a clear statement.

For some additional context, I think the current naming makes sense and
works in Qubes. When it was proposed to me I endorsed it - I believe
that Marek had been consulted in Matrix before the current scheme was
instituted, but I could be wrong. I dont think that matters.

It seems to me that this is prime bike-shedding. We have a scheme that
works for us. I doubt that any user will be confused about where to look
now we have explicit versioning. I do agree that it would be desirable
to document the naming scheme. I dont think we have control over
placement of links in the menu, and I dont think that matters.

As I have pointed out in the past, for a relatively stable link use the
versioned address - even this will not guard against link rot, but it's
the best we can do.

unman

[Ben Grande]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, "latest" is ambiguous. I showed various projects that use "latest"
for what we currently has as "development". The first project mentioned
on this thread that use "latest" as the current stable release is
Fedora, and they have "latest" in the URl but in the branch chooser it
is still called "f44".

Can we change the name "latest" to either "stable" or "latest-stable" if
worried about simultaneous stable releases?

- --
Best regards,
Benjamin Grande

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCamnuIgAKCRAbcxS/DMyW
h+/rAP4jd/vjgokcJjB1pPALdQlfsaNgd6Lk7yq6b2xI5qIv+wD/Y2azq9Q0wzJM
1tSyfr0mYKrOeJnlrrooTDFdZTX1AQM=
=3qkH
-----END PGP SIGNATURE-----

[Ben Grande]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Thanks Simon for a clear statement.
>
> For some additional context, I think the current naming makes sense and
> works in Qubes. When it was proposed to me I endorsed it - I believe
> that Marek had been consulted in Matrix before the current scheme was
> instituted, but I could be wrong. I dont think that matters.
>
> It seems to me that this is prime bike-shedding. We have a scheme that
> works for us. I doubt that any user will be confused about where to look
> now we have explicit versioning.

With your response, you said simply "we decided this way", not "why this
was chosen". So the reasoning was not clarified.

I am confused. We are using "latest" for the "stable" release, which I
replied on my previous message to Simon, that only Fedora from the
examples shared, does that. The name "latest" is only clear once someone
reads "development", so they guess that "latest" should be last stable
release.

If we want to roll our own naming scheme, it will make users like me
confused, as we are differing from the naming scheme used by other
projects.

> I do agree that it would be desirable
> to document the naming scheme. I dont think we have control over
> placement of links in the menu, and I dont think that matters.

https://borgbackup.readthedocs.io/en/stable/

- - latest
- - stable
- - number
- - master
- - changelog-number
- - numnbers

It is not alphanumeric the current sorting, but I don't know if they
chose that or RTD has some weird built-in sorting or is based on branch
activity, because it appears weird that "master" comes after numbered
versions while "stable" comes before, so I don't know if they made that
choice explicitly.

> As I have pointed out in the past, for a relatively stable link use the
> versioned address - even this will not guard against link rot, but it's
> the best we can do.

I like the stable link. I pointed that other projects default to use
names instead of version in the links. Can we do that instead of
defaulting to "r4.3"?

- --
Best regards,
Benjamin Grande
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCamnyhAAKCRAbcxS/DMyW
h2OtAQCkTfhV5Lty9M7mNHKWH3Hb9L7zJxhYsRKHdw8/GKdtaQD+Ix9phRakVdWN
sCR7iQScdtORgixPC2CtMGqFn5ooBQY=
=NI4l
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ben Grande, 2026-07-29 14:12 +02:00:

As I tried to argue above, in my experience there are very many
variations of how things are named and how versioning is handled in
general. So there isn't one standard way to do it and you will find for
almost every variant some examples. For example for "latest" == "latest
release", 3 other examples:

https://www.jj-vcs.dev/latest/
https://docs.ansible.com/projects/ansible/latest/
https://docs.saltproject.io/en/latest/contents.html

The later 2 are particular close to what we have (except that Ansible
also list the unreleased version by it's number).

> Can we change the name "latest" to either "stable" or "latest-stable" if
> worried about simultaneous stable releases?

If changing it I would go for "latest-release" but "stable" is ok too, I
think.

Since I missed to include this in my first response: Naming things is
hard and I don't think there's one correct answer here. Just wanted to
point out that from my perspective the current scheme is good.

In the end I think this is something for the doc maintainers to decide.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmpqA7MACgkQkO9xfO/x
ly86YRAAv3NHnCPYq2b2uKOJjuG3wJmIwhLQK6NeH0oO2fENfwtNSKOaB6rRgCwN
FLPQwxspkJh0exo/NkWZGcewXyHyFTuV7+RvPLiJliA1e3WwcExJmBJikJtjBKv8
B1jYNsdEzuBLivO2nyVPKzCaTW1oxeb0D3fCqycwordLjDa7DGqm+TXAoTM4G7ot
n0eM5ScU9wxVEr8aWiM0vRjfYSuC1XL+Ra7Pf8o/XBhvxRxa3EX+fd8X6ZVRy7Yo
iFGkUqP2GtyCOjP25XJnP40RiptFhGcWYZcH4XYTxr2JCQpWNEYkrj0sVLpBtFaV
DseWTRP36qa9EFURBeYMJMFKIJIdc9NzVBX0rqEsgzEyB+PvNxyKXOEiKwwjgFkP
6V+XatWrVY4q0OCAPNy8zntO3gnSL+eZ/oThCYYQkx548qGt9JFMzYB1gn7wIU2Y
l1G/zUidCKdVVY3/5iA+gFg8y2QHh/m3cmiSN3lx4RCD5MpJ6F7cqrYb5VtKl7Vj
bJH46rsL+WMXqk5zpg9iPhI9Subr+XZwtvy3KIvIpLtLhi6Ldda7M2HBHiSiLlxw
z8Wi2FkmzJ42gWuZGyQ9AXeQaCtJ+bbrzXNwvdr8ThoA9Zecy6NWTRULFjWyIoGS
fKnXB8Y+PtQyHqgzFMyKtlQCsFzjyuyJUf3FFGvnBv4QROyR5Kk=
=hJiZ
-----END PGP SIGNATURE-----

[Ben Grande]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26-07-29 15:45:45, Simon Gaiser wrote:
> Since I missed to include this in my first response: Naming things is
> hard and I don't think there's one correct answer here. Just wanted to
> point out that from my perspective the current scheme is good.
>
> In the end I think this is something for the doc maintainers to decide.

I don't plan to reopen the issue if my propositions aren't heeded. I
will let it be with just "documentation of the naming scheme", which was
already heeded by Unman on the other e-mail.

- --
Best regards,
Benjamin Grande
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCamoNjgAKCRAbcxS/DMyW
h0efAP4jixMjTnEN+KU3yFtGp7J5Guv+LwVZ11lUJZ0/HAzP+AEApTomy9iYeTQq
v2GTnDzN4kO9tyRyMNqk1OzWZ9fb9wA=
=RNbN
-----END PGP SIGNATURE-----

[parulin]

Take a look at my pull requests addressing a related issue:

* https://github.com/QubesOS/qubes-issues/issues/10263
* https://github.com/QubesOS/qubes-doc/pull/1742
* https://github.com/QubesOS/qubes-doc/pull/1743

With the title of the page and an admonition at the very beginning of
the file, telling the user about a potential "wrong" version, I don't
think that having "development" or "latest" or "stable" as the name will
be very important...

The preview of #1742 doesn't display the development admonition because
it is a PR, but it will look like the one on the r4.2 version.

[Andrew David Wong]

On 7/29/26 6:45 AM, Simon Gaiser wrote:
> Ben Grande, 2026-07-29 14:12 +02:00:

[...]

>> Can we change the name "latest" to either "stable" or "latest-stable" if
>> worried about simultaneous stable releases?
>
> If changing it I would go for "latest-release" but "stable" is ok too, I
> think.

[...]
As Ben hinted, "stable" is ambiguous when there's more than one stable, supported release at the same time. Not long ago, both 4.2 and 4.3 were both stable and supported, so "stable" applied to both of them equally.

"latest-release" is better, but it could apply to a testing release, such as a release candidate (RC), so it's still more ambiguous than "latest-stable."

I suppose "latest-stable" could be interpreted as something other than a release, such as "latest stable documentation build," so "latest-stable-release" would be even less ambiguous, but it's quite long.