Release Planning 1.x.x

Platform-First Planning

The main goal is to develop a usable general-purpose operating system platform, not to finish one individual component to perfection or to achieve complete technological self-sufficiency. However, being very interdependent, the OS “release versions” should coincide with some individual components becoming more stable.

Necessary & Nice Features

For an okay-ish release version it will be necessary to finish some things:

• More documentation (especially of bugs/limitations)
• Reasonably stable kernel
• Reliable demos
• Some useful drivers/modules
• Build system improvements for “release builds”
• Downloads & backups for each release

For a perfect release version it would be nice to have:

• Fully new kernel code
• Bug-free C compiler
• Fully self-hosting codebase edit/compile/test
• Extensive manual pages
• Usable graphics/networking support
• Full packaging & versioning of each component
• Lots of new kernel features like dynamic modules

A Modest 1.x Release Plan

The “necessary” features can be thrown together very easily in a limited form if need be but working towards “nice” features should dictate the actual targets for a meaningful “point zero” release.

So I’ll revise my planning a little as I do further tests but I’ll probably drop a “first full release” version once I’ve finished off some more “nice” features.

A Possible Trick

As most of the code doesn’t currently have a versioning scheme but is already in a mostly working state, one trick I might use is to just bump up the kernel version automatically to 1.x.x based on the xx% replacement of legacy code and base the platform version on that.

This would make the initial releases smooth 1.x.x values starting around 1.7.0 or 1.8.0 while avoiding any possibility of perpetual “0.9.9 final beta 10 almost finished” type releases, while an eventual 2.0 release down the track would be the “fully new kernel code & stable API” release.

On the other hand if these milestones approach too quickly it would be pointless to call a final version 2.0 I might as well just do 0.8, 0.9, 1.0. So I’ll see how I go with some upcoming features and work from there!