Clock ticks towards 5:30 finishing time
Posted by Steve Revill Thu, 29 Sep 2022 14:13:00 GMT
Every eighteen months or so the hands on the clock point at stable-o-clock, the time when we assess all the platforms on which RISC OS runs and determine which are polished enough to meet the unchanging stable release criteria. In addition, new features and any particularly irksome faults are added to the mix.
What areas are involved
Ports
All nine of the ports for which the source code is published are up for nomination, with three of those (i.MX6, OMAP5, and Pinebook) hoping to transition from red to amber or green for the first time, and the other six hoping to retain their status.
Features
Principally driven by the bounties and major roadmap items, there’s always a nice clutch of features to roll into a stable release. There’s still work to do though, with sixteen features targeted.
Defects
There’s usually around 600 distinct changes to the source code collated over the entire (odd numbered) development cycle. In preparation for a stable release we also review the open bugs and bug forum threads for any that got missed. There’s still work to do though, with nineteen defects targeted.
CC-BY Matt Brown
What you can do
If you’re a developer
Why not pick up one of the unassigned tasks from the task list? Or partner with one of the other developers to help them test or review their work. Remember, if you’re a new developer to RISC OS we can sponsor you a copy of the Desktop Development Environment if you’ve a hunger to get started.
If you’re not a developer
Don’t worry if you’re not into coding, why not flick through the User Guide looking for typos or improvements to make? You can either put these directly into the wiki page, or email them to the reader’s comments address.
It’s also useful if as many people as possible are running the preview versions available from the downloads page. It’s only through testing that issues are uncovered – We don’t want everyone waiting until the new version is finalised, only to discover a bug that was missed because nobody was running the preview versions!
What we’ll be doing
Each week any traffic going past in GitLab will be checked against the tables of features & defects & ports being worked on, should it be possible to mark them as done. From time to time the User Guide Editor will also sweep up any documentation feedback.
Then, monthly, a new set of release candidate images will be generated with all the prospective components incorporated.
As a technical aside: whenever the version number rolls over to a multiple of 0.10 (as it will do here from 5.28 to 5.30) the Boot application gets an opportunity to make significant changes. Therefore the release candidates will report a 5.3x series version number to ensure the corresponding disc based changes are activated too.
How does this cycle end?
Based on experience it’s clear when the release candidates are converging, and that’s the time when, in order to bring the process to a close, some incomplete ports or features may be dropped. They’ll have to rollover to the 5.31 development versions as there wasn’t time or programmers available to do the work.
Nice, thx for the update.
Quick question on this task:
“Design some alternate iconbar tile sprites building on Wimp’s new background tile feature”
Does that means now the IconBar supports different tile sprites than regular Windows? If so which name should I use for those? Thx!
The CM4 has two issues – mouse freeze (hardware work around) and on board 8 bit eMMc2 storage (not readable by RISC OS). Otherwise it works (by booting from USB).
Is this fixable?
Seems that it is fixable, see bug tickets. Well done!