Very well stated. The goofy names don’t add any worthy advantage. Just stick with 8.3 and 8.4, etc. and that says it all.
I agree with you guys, it’s a distraction and generates confusion.
I vote to keep the naming convention as simple as “Rocky Linux [version number based on the official RHEL release version number]” for example Rocky Linux 8.3
1 Like
Yep. In line with RHEL, we’ll probably be sticking to SemVer-ish release numbering. Maybe we’ll have nicknames for the releases but I doubt that at the moment. 
I think it should be called rocky!
However, I think for each version though it should be types of rocks from smallest to largest.
Clay >> Silt >> Sand >> Pebble >> Cobble >> Boulder
.
.
or something like that!!
1 Like
Could see the possible need for some form of ID of work on a release that could occur prior to the official number being out yet. But since I have no knowledge in what all goes on behind the scenes of building a distro I could be spouting complete jibberish.
numbers are boring for version names, it should be, VersionName.XX
My vote is on version numbers. Much like how I name my servers like cattle (int-nc-sql-01) so I can figure out what the heck it is and where it is, having a YY.MM version or build number is preferred. Like 21.03 tells me exactly when it was released and it’s easy to figure out when the EOL is. I’m alright if the cutesy names are used as secondary identification, such as the way Linux Mint does it. Emphasis goes on the version number, not the name.
1 Like
if the concept of rocky is to be as close as possible of a RHEL linux, the version number of rocky must follow the RHEL version.
I think about RHEL CVE or install documentation, the user should know immediatly the matching versions of rocky.
Maybe there is places for guffy stuff in the resources and brandings !
2 Likes
I think that Rocky Linux should follow the numbering of RHEL. However, I don’t think it would hurt to give releases names. Why? Allow me to repost a link sent by @quazarzero: https://www.connectsolutions.ch/blog/how-fun-at-work-can-increase-productivity-and-employee-engagement
It could also help to avoid confusion between different versions.
Some naming ideas (some reposts):
- Mountains (e.g. K2, Cheviot, Rushmore, etc.)
- Planets (could be fictional as well as real)
- Rocks (e.g. Granite, Obsidian, Sandstone, etc.)
- Elements (e.g. Bismuth, Carbon, Osmium, etc.)
Looking forward to the first release!
Hello,
This post has caught my attention with release naming. I concur about sticking to RHEL name 8.1, 8.2, etc… But I do like names of Greek Gods…
THE OUREA were the primordial gods (protogenoi) of the mountains.
For example, OREIOS (Oreus) The mountain-god of Mount Othrys in Malis .
Zeus.Hera.Athena.Apollo.Poseidon.Ares.Artemis.Demeter.
Just suggestion.
1 Like
The external name should just be the RHEL version number. Whilst it may be convenient for some to encode the release date within the number, experience has shown that real world users stick to the simple numbers: CentOS 7.2009 is usually called CentOS 7.9 regardless of the “official” position. Generating cute names is likewise fraught with problems. If they are an ordered sequence, what happens when you get to the end of the sequence? Next, CentOS is not just used in America; non-anglophones will spell and pronounce names differently. Consider the case of “Hercules” or “Heracles” or “Herakles” or even Greek orthography!
1 Like
I like your point about naming, however I have no hard opinion on using names or not since RHEL currently uses names but CentOS didn’t.
My thoughts:
- Limiting changes to “de facto” upstream standards like numbering conventions is preferred
- Use what creates the least amount of ongoing maintenance work for packaging/release teams
Basically learn from past mistakes and reduce complexity within any automation.