etc/os-release: Add the version number to the PRETTY_NAME
Merge request reports
Activity
Debian uses
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
so this makes sense to me, i wonder if we should go even further and usePureOS 10.0 (byzantium)
since we usually refer by codename. (I'll leave that to @jeremiah.foster and @matthias.klumpp to decide though)
requested review from @jeremiah.foster
Personally I would prefer a pretty name with just a plain version number, so "PureOS 10". That is because it permits us to release patched versions and arbitrary times without touching the base-files package (the patch-version is kind of arbitrary anyway) and will not confuse users as to whether they have the latest "10.4" version. Not having the codename in the pretty name bit is a preference - this name is shown in various places in GUIs, and especially in longer texts "PureOS 10 (byzantium)" looks very noisy. Generally I would hope users don't need to know the codename of the OS unless they want to deep dive into the system. Of course, an argument could also be made though that always mentioning version+codename is good so people don't forget and communication is "complete", which I think is a valid argument as well. So having the reduced set of information is mostly personal preference.
@matthias.klumpp would
PRETTY_NAME="PureOS 10 (byzantium)"
work for you then? We'd drop the patch version but have the prominently used name 'byzantium' easily available.
mentioned in merge request !2 (merged)
Is it a good thing though if users know the codename more than the version? ^^ I think in the (graphical) UI, having a shorter less verbose version/name string is quite a bit nicer. I'll take a few screenshots and also have a look how the installer looks like with longer strings for release names.
The issue is that Purism in blog posts, etc talks a lot about
Byzantium
not so much about10
. We can fix that for11
but forByzamtium
it's likely already too late.N.B. I personally think code names in a prominnent place (especially if they follow a pattern
a
->b
->c
-> … are a good thing to identify releaeses.Thanks for having a look at the installer.
While it's not awful, I do very much prefer the version-number-only approach, still. We had this debate in Ubuntu a while back, I think (I tried to find references to it, but couldn't find any), and back then it was decided to only show codenames in technical documentation and not shove them into the user's face. Reason was that codenames are opaque to users to some extent, they require some insider knowledge to make sense of ("what is the "byzantium" behind the version?"), and make it non-obvious what version is the latest version or if the user is on the latest OS version (our codenames are alphabetically sorted, but that is something you have to know and is not immediately obvious to users). Version numbers on the other hand can be trivially sorted by people and are well established and easily understood. In my opinion, having less redundant information on screen is preferred over having more information displayed that users might just wonder about.
I do get the argument that all the informational material was only talking about
byzantium
so far - IMHO that was a mistake, but it would warrant adding the name at least for the byzantium release (it may be odd for new users which did not follow our blog, but make the experience better for users who do know the technical details).I do get the argument that all the informational material was only talking about
byzantium
so far - IMHO that was a mistake, but it would warrant adding the name at least for the byzantium release (it may be odd for new users which did not follow our blog, but make the experience better for users who do know the technical details).Using it for byzantium and droppping it for
color-starting-with-c
sounds good to me if we communicate the new name^Wnumber clearly. I assume @jeremiah.foster would spread the work here?assigned to @matthias.klumpp
This is done via 79b08766