Stable Releases

Overview

Since RISC OS 5.14, ROOL have used the even numbers are stable version numbers to describe each major release, and odd numbers (eg. 5.15) for the intermediate development versions. However, the term ‘stable’ embodies quite a few different concepts.

Firstly, it’s not a reference to how many times the operating system crashes. Many of the nightly builds will run perfectly satisfactorily and be reliable in day to day use. Secondly, a stable release (like any software) will contain some bugs, the key difference is that for a stable release the bugs are at least known or not categorised as significant.

Requirements

Although in theory anyone could edit the source code to make the version shown be even, only those vetted by ROOL and marked as such are deemed stable. We carefully determine which releases are marked as stable based on a number of factors:

• Programmer’s interfaces
  • Any newly introduced APIs should be finalised and run past ROOL to check they make provision for future hardware. For example a video capture module that works with the Raspberry Pi camera may well be hardware specific, but the API can be designed to support other camera modules in future.
  • Any extensions to existing APIs should be finalised, and extended in as backwards compatible manner as practical. Such extensions should be documented in the style that the PRM uses, at least in the wiki version of the PRM.
  • Part of the guarantee of a stable release is that programmer’s can rely on (and test for) APIs and that they will be continue to be supported in the future.
  • Updates to other disc based applications that your platform relies upon should also have been made, for example a stable port using RGB video memory layout should check the applications in HardDisc4 can display such images.

• Modules
  • Module names, SWI bases, error bases etc… must be registered using the normal allocation service to avoid clashes.
  • ROM based modules must be internationalised via MessageTrans, with default en-gb translations in ResourceFS.
  • Disc based modules can use fixed en-gb strings, since international users can replace those easily by copying a localised version on top.

• Peripherals
  • Accessible plugs and sockets for which there are support in contemporary platforms should be similarly supported; for example a Risc PC’s serial port is supported, but the Iyonix microphone input is not – hence for any stable releases this same level of support is OK.
  • Inaccessible or internal plugs and sockets need not be supported, or can be powered down.

• Hardware abstraction
  • Generally the main difference between platforms are involved in the HAL; video; USB; and ethernet, though some platforms might share some of these.
  • Each must implement the entry points that their contemporaries do. For example some of the ‘boilerplate’ HAL calls to report system information such as the memory map arrangement, platform name, and platform flags aren’t needed to boot a computer but since they form part of a stable API must be implemented.
  • All GraphicsV entry points are implemented.
  • USB bulk, control, and interrupt end points are supported.
  • USB sockets act upon overcurrent situations.
  • An autosense file is provided for any new ethernet driver(s), which abandons gracefully on systems that don’t include that driver. The info/self test commands are implemented and follow the general form of the other ethernet drivers (eg. EtherK).

• Administrative
  • A products file must be provided listing the tags of all the components included, and corresponding components file
  • If a previous stable release exists, the (autogenerated) change logs must be made available based on the previous products file. Newly stable platforms can’t provide this, so isn’t needed.
  • The port status page should reflect the current status of any known unresolvable problems, for example the OMAP4 can’t implement < 8bpp screen modes due to a silicon defect.

Note, it is not necessary to perform a source code level review to gain the stable badge. A sample unit can be provided for black box testing, though commercial customers would be expected to reimburse ROOL for the test time involved.