AmigaOS 3.1 API compatibility
We exclude parts which are deemed to be non-portable or obsolete
and not worth the effort and implement the remaining API.
To mark something as obsolete even though it is possible to implement in a
portable way should require good reasons; for example if it is very rarely
used by applications and the effort required to implement it is
substantial.
Current status: In Progress, 81% Completed, see Status page
Current recommendations: see Recommendations
Partial AmigaOS 3.5 and 3.9 API compatibility
We choose the parts that we feel are useful and worthwhile to have, and
ditch the rest. For example, it seems very unlikely that we want
ReAction compatibility since we have already chosen to standardize on Zune
for the GUI toolkit (and implementing the ReAction API is not a
trivial undertaking).
Some parts of 3.5 and 3.9 are already implemented. They can be found in
Extensions section of Status page
Current status: Skipped
Reasoning: This goal is defined a in way that does not allow benchmarking
its completeness.
Completed GUI toolkit
This means Zune must have complete MUI 3.8 API compatibility and a
finished preferences program.
Current status: In Progress, see Zune page
Current recommendations: see Recommendations
Standard applications comparable to those which come with AmigaOS 3.1
This does not mean that we have to have the exact same applications which
work exactly the same as in AmigaOS, but the functionality available to the
user should be roughly equivalent.
Current status: In Progress, 73% Completed, see Programs page
Current recommendations: see Recommendations
Sound support
API compatibility and basic applications. There should be at least one
driver for each mandatory port.
Current status: Completed
Reasoning: Currently AHI is ported, and there are some drivers (a few)
for i386-port. AHI Preferences editor as well as MP3 player are
available.
Networking support
This includes a TCP/IP-stack and some basic applications, like email and
SSH clients, and also a web browser. There should be at least one NIC
driver for each mandatory port.
The requirements on the web browser should not be high, but it should be
possible to at least browse the web in some way.
Current status: Completed
Reasoning: AROSTCP we got now is an ancient but working implementation of
the AmiTCP stack. There are several network drivers available for both
real hardware and Linux hosted TAP device. The AROSTCP preferences editor
is available. Network applications are available: ftp client, IRC client,
mail program, modern web browser, etc.
Self-hosted development environment and SDK for developers
Specifically, this includes all software required to build AROS, like
GCC, GNU binutils, GNU make and the rest. It must be possible to compile
AROS on AROS.
The ABI for the supported architectures (only i386 at this point) must be
finalized before 1.0. Once 1.0 is released, the ABI should be stable for a
considerable time.
Current status: In Progress
Current recommendations: see Recommendations
Comprehensive documentation for developers
This includes reference manuals over all libraries, devices,
classes and development tools and also guides and tutorials to
introduce whole subsystems and give an overview. Also, a migration/porting
guide should be available.
Current status: In Progress
Current recommendations: see Recommendations
Comprehensive documentation for users
This includes a complete command reference, tutorials, and an installation
guide and a configuration guide, as well as other guides.
Current status: In Progress
Current recommendations: see Recommendations
Reasoning: Documentation exists and has extensively been translated to
different languages. To be complete, the tutorials and guides, and the
help system are needed.
Substantial testing and bug hunting complete
The 1.0 release should be virtually free of bugs, and be a very stable
release. We should not have the fiascos some open source projects
have had with their ".0" releases.
This will probably require an extended feature freeze, followed by a code
freeze and several intermediate milestones for user feedback and testing.
Feature requests are not regarded as bugs, unless it is something required
(but missed) in the preceding milestones. For example, "we need a movie
player" does not qualify, but "the text editor should have a 'save' menu
option" does.
Current status: Not Started
Current recommendations: see Recommendations
Reasoning: Currently no freeze can be done as features aren't complete
yet. There is still lot of unfixed bugs, but increasing users activity looks
promising. Bug hunting and accounting procedures and services are wanted.
