Not sure if it's still the same as it was back in my day, but KDE's "release candidate" nomenclature was always a bit of a misnomer. You'd never see RC1 actually released as final. What it really means is that the alpha "feature refinement" beta "bug fixing" phase is over, and it's the final testing phase for showstoppers. However, the definition of showstopper seemed always to be very wide. Thus, a lot of bugs still get reported and fixed during this phase, and RC really means "beta, but towards the end of the pipeline".
Which is in contrast to the Linux kernel where a RC can be declared ship-ready and simply get renamed.
Admittedly there's a fairly large impact difference between kernel level bugs, and say a bug in Okular...
The nomenclature is actually correct here, and a lot of other software use it, at least from everything I've seen. Release candidate means it's stable and (usually) feature complete but could have bugs and needs testing before they launch it.
This is at least somewhat common. In fact, it's the same way the Linux kernel development cycle works. They have 7 release candidates, released on a weekly basis between the beta period and final release. See: https://www.kernel.org/category/releases.html
In the world of proprietary corporate software, I more often see release candidates presented as potentially final; i.e. literal candidates for release. The idea of scheduling multiple RCs in advance doesn't make sense in that context, since each one is intended to be the last (with fingers crossed).
It's kind of splitting hairs, honestly, and I suspect this distinction has more to do with the transparency of open-source projects than anything else. Apple, for example, may indeed have a schedule for multiple macOS RCs right from the start and simply choose not to share that information. They present every "release candidate" as being potentially the final version (and indeed, the final version will be the same build as the final RC), but in practice there's always more than one. Also, Apple is hardly an ideal example to follow, since they've apparently never even heard of semantic version numbering. Major compatibility-breaking changes are often introduced in minor point releases. It's infuriating. But I digress.
If you're as old as I am, you'll recall software using the term "gamma" release instead of "release candidate" for that phase. ;)
It’s still a misuse of the word - if your software needs testing it’s not a candidate you would release unless you’re a multi-billion gaming company or Cisco
Production releases still need testing. There are always bugs you don't know about hiding somewhere in projects or vast complexity.
There are, but if none are found it can be released - like apple and Microsoft sometimes does.
It’s what you put in it I guess. For me that’s “Hopefully ready but it’s what we’re shipping in features and functionality”
Wiktionary: (software engineering) A version of a program that is nearly ready for release but may still have a few bugs; the status between beta version and release version.
Oxford: a version of a product, especially computer software, that is fully developed and nearly ready to be made available to the public. It comes after the beta version.
I couldn't find more definitions from "big" dictionaries, but literally no definition I've seen agrees with you. I wonder why that is.
Plasma 5 made me a KDE user and fanboy. I am super excited to see what 6 will bring.
KDE team, you rock.
Any exciting features coming up with plasma 6?
HDR support is the feature I'm mostly looking forward to.
Will we get tabbed/grouped windows finally again? Been waiting for this for half more than a decade.
I'm a bit curious about why you have been waiting for it "only" for half a decade, since that feature was gone since 5.0, more than a decade now.
All in all there have been no mention of it coming back whatsoever, and for what I understand they removed it because the code behind it was causing lots of trouble with Qt5 and was impossible to mantain. And they've stated they won't be reviving this feature.
Fair point, edited.
I am still hoping beyond hope they do revive it, there seems to be others that do as well.
I can't wait to try this out!
Well then do it! There's probably VM images around with a working installation
I never understood the Wayland hate until I tried to get it working with KDE Plasma on a Orange Pi.
Planning on testing for bugs, I'm super excited for this release!
Hopefully it will fix the few remaining Wayland bugs I've been experiencing and I can move 100% onto Wayland when Nobara upgrades to plasma 6.
Not sure if it's still the same as it was back in my day, but KDE's "release candidate" nomenclature was always a bit of a misnomer. You'd never see RC1 actually released as final. What it really means is that the alpha "feature refinement" beta "bug fixing" phase is over, and it's the final testing phase for showstoppers. However, the definition of showstopper seemed always to be very wide. Thus, a lot of bugs still get reported and fixed during this phase, and RC really means "beta, but towards the end of the pipeline".
Which is in contrast to the Linux kernel where a RC can be declared ship-ready and simply get renamed.
Admittedly there's a fairly large impact difference between kernel level bugs, and say a bug in Okular...
The nomenclature is actually correct here, and a lot of other software use it, at least from everything I've seen. Release candidate means it's stable and (usually) feature complete but could have bugs and needs testing before they launch it.
Prototype --> Alpha --> Beta --> Release Candidate --> Release
This is correct, albeit not universal.
KDE has a predefined schedule for "release candidates", which includes RC2 later this month. So "RC1" is clearly not going to be the final version. See: https://community.kde.org/Schedules/February_2024_MegaRelease
This is at least somewhat common. In fact, it's the same way the Linux kernel development cycle works. They have 7 release candidates, released on a weekly basis between the beta period and final release. See: https://www.kernel.org/category/releases.html
In the world of proprietary corporate software, I more often see release candidates presented as potentially final; i.e. literal candidates for release. The idea of scheduling multiple RCs in advance doesn't make sense in that context, since each one is intended to be the last (with fingers crossed).
It's kind of splitting hairs, honestly, and I suspect this distinction has more to do with the transparency of open-source projects than anything else. Apple, for example, may indeed have a schedule for multiple macOS RCs right from the start and simply choose not to share that information. They present every "release candidate" as being potentially the final version (and indeed, the final version will be the same build as the final RC), but in practice there's always more than one. Also, Apple is hardly an ideal example to follow, since they've apparently never even heard of semantic version numbering. Major compatibility-breaking changes are often introduced in minor point releases. It's infuriating. But I digress.
If you're as old as I am, you'll recall software using the term "gamma" release instead of "release candidate" for that phase. ;)
It’s still a misuse of the word - if your software needs testing it’s not a candidate you would release unless you’re a multi-billion gaming company or Cisco
Production releases still need testing. There are always bugs you don't know about hiding somewhere in projects or vast complexity.
There are, but if none are found it can be released - like apple and Microsoft sometimes does.
It’s what you put in it I guess. For me that’s “Hopefully ready but it’s what we’re shipping in features and functionality”
Wiktionary: (software engineering) A version of a program that is nearly ready for release but may still have a few bugs; the status between beta version and release version.
Oxford: a version of a product, especially computer software, that is fully developed and nearly ready to be made available to the public. It comes after the beta version.
I couldn't find more definitions from "big" dictionaries, but literally no definition I've seen agrees with you. I wonder why that is.
Plasma 5 made me a KDE user and fanboy. I am super excited to see what 6 will bring.
KDE team, you rock.
Any exciting features coming up with plasma 6?
HDR support is the feature I'm mostly looking forward to.
Will we get tabbed/grouped windows finally again? Been waiting for this for
halfmore than a decade.I'm a bit curious about why you have been waiting for it "only" for half a decade, since that feature was gone since 5.0, more than a decade now.
All in all there have been no mention of it coming back whatsoever, and for what I understand they removed it because the code behind it was causing lots of trouble with Qt5 and was impossible to mantain. And they've stated they won't be reviving this feature.
Fair point, edited.
I am still hoping beyond hope they do revive it, there seems to be others that do as well.
I can't wait to try this out!
Well then do it! There's probably VM images around with a working installation
I never understood the Wayland hate until I tried to get it working with KDE Plasma on a Orange Pi.