Forward compatibility for potential incompatible changes
Before releasing Sortix 1.1, plan for potential incompatible changes in Sortix 1.2:
- Renaming /boot/sortix.bin to /boot/kernel.
- Renaming /boot/sortix.bin to somethinng else perhaps /boot/initrd or /boot/kernel.initrd.
- Discontinuing /etc/machine perhaps in favor of sortix-release or moving it to /lib/machine.
- Possibly moving /etc/sortix-release to another location.
- Additional metadata (sha256sum, permissions) in the tix format.
- Changes to the release.sh format.
- Changes to the release directory layout.
- Splitting the system manifest into one per component.
- Turning the system manifests into a real tix binary package.
- Ability to rename ports and ports that require each other.
- The consequences of dynamic linking on the upgrade mechanism.
- A supported script or makefile target for upgrading 1.1 to 1.2 ala the 1.0->1.1 bootstrap guide.
- Ability to issue new signing keys.
- What happens to non-root collections with ports across ABI changes.
- The HTTPS apocalypse when the known root certificates expires or the server has no TLS versions or ciphers in common with Sortix 1.1.
- Changing the initrd format to something else than tar.
- Changing the machine in the platform triplet.
- Change in compression format.
- New version number scheme.
(and brainstorm more)
Edited by Jonas Termansen