Is there any plan to give sweet little names to releases ?
Rocky Linux 8 : Balboa ? Free Beer Edition ? 15 minutes before global collapse edition ?
2 Likes
Or a pathern for version naming ? (tv show ppl, fruits, planet…)
1 Like
I really hope that there will be no release names. It might be funny but is something for consumer distributions.
Fedora got rid of the names for releases years ago. The release names are like jokes if you have to explain them then they no longer funny. Also, you will offend a large part of the community at one point and the process to choose a release name consumes resources which could be used elsewhere much better.
From my point of view, Rocky Linux should simply stick to the established release naming schema of CentOS.
Who can me when will “Trusty Tahr” be EOL without googling? And when was CentOS 7.5-1804 EOL?
13 Likes
I think release code names are not necessarily a bad things - at least for internal use.
If we do go down that route, I would suggest Stallone films/characters. I know the project is not named after the Rocky films, but it is an opportunity too good to miss 
1 Like
I am with @fab no need for names, stick to the pragmatic, boring approach. It does make things clear.
8 Likes
I’d prefer no names. It’s annoying to have to look up what version numbers the code names correspond to when working in the Debian/Ubuntu world.
8 Likes
Rocky Linux is going to be an enterprise Linux Distribution. Naming with fruits,cakes,cities, etc. will lead this project to kids project instead of An Enterprise Project. I vote for regular numbers. 1, 2 ,3 , etc
5 Likes
Better spend the time for „better“.
I suggest the first version should be rocky 8…
5 Likes
So I understand the point being made about the boring pragmatic option as being the easiest to achieve the same goal as CentOS. But that is the thing we are not CentOS anymore, we might want to make an OS with the same values as before RHEL goofed, but why do the exactly the same thing? Although the enterprise world is not meant for kid like jokes, it is harder to sell, I agree with that let’s find a middle ground.
With that in mind, LTS releases are mountain ranges, medium updates (6m) singular mountain, minor updates are pebbles? if we follow that type of release cycle? which I do not believe is even set in stone yet.
The support the Geological approach on this.
Besides the Goofy factor, what does this buy us? Does it help with identifying releases?
IMHO, it’s a distraction at most.
2 Likes
Being serious, a lot of programs use “lsb_release -r -s”, /etc/redhat-release, or /etc/system-release to determine whether they work or not. One thing I strongly disliked about CentOS, is that it departed from the RHEL format, and this caused programs to break that would otherwise just work. Oracle Linux chose to preserve the RHEL format, and “just works”. I know there is a branding legal problem, and a community has fewer lawyers than Oracle does to enforce legal rights (or just make it problematic to challenge them), but if the goal is to be a free rebuild of RHEL, I think i should follow RHEL as closely as legally possible, and not try to follow CentOS at all.
3 Likes
Free Beer Edition
@quazarzero Rocky Linux 8: It’s Biru Taimu
I fully agree. As an Enterprise Linux distribution, be professional. So, no naming necessary.
3 Likes
Besides the Goofy factor, what does this buy us? Does it help with identifying releases?
1 Like
How about if we named after famous boxer? Like Tyson, Ali, Mayweather, Foreman, etc… Just a suggestion.
I suggest a Major.Minor.Date schema. 8.1.202102 as an example. The date could be just a YYYYMM or YYYYMMNN, where the NN is an incrementing number that per month resets. 8.1.20210305 for this example.
What about “mountains”?..after all “ROCKY” as in “The Rocikies”…after individual mountains…Mt. McKinley…Mt. Ranier…My. Rushmore?..and then you could go “international” for the ones that are “development / testing” versions…Mt. Vesuvius…Mt. Kilimanjaro…Jotunheimen…Mt. Fuji etc.
No need for the naming I guess.
Just smart and simple versioning will be OK.
And I also think Rocky should start from the version 1 and not copy upstream versioning.
1 Like
just like what LinuxGuy says but like name it from the smallest mountains to the largest for every new release