Home A - Z
Page Index

Roadmap and Scope

Documentation baseline: VoxelCore main at 452b569 · 14 September 2026.
Repository: https://github.com/VoxelHorizons/VoxelCore

This page separates what the wider VoxelCore rebuild plans to become from what the current item/content MVP already supports.

Current completed foundation

The present implementation has realised several early roadmap principles:

  • deterministic content discovery and bounded YAML parsing;
  • explicit single-parent inheritance with cycle/missing-parent validation;
  • immutable compiled definitions;
  • atomic runtime snapshot publication and failed-reload preservation;
  • stable ContentID separate from rendering identifiers;
  • shared persistent render-allocation authority;
  • deterministic Java resource-pack compilation;
  • explicit version adapters and exact pack profiles;
  • real-server CI behaviour checks instead of enable-line-only CI;
  • non-destructive config schema migration.

Next system classes

The broader migration roadmap still calls for systems beyond this MVP. Current README/source explicitly leaves these outside the supported item milestone:

  • placed custom blocks;
  • furniture, seats, storage, light and display-entity lifecycle;
  • vehicles/input/simulation;
  • crops and bounded growth scheduling;
  • GUI/menu framework and session lifecycle;
  • Bedrock/Geyser frontend mappings and presentation;
  • richer version-aware item metadata;
  • legacy HavenCore import/compatibility paths.

Architectural direction from the migration roadmap

The planning document recommends maintaining a distinction between:

  • immutable content definitions;
  • individual item instance state;
  • persistent world placement state;
  • replaceable render handles.

It also proposes keeping gameplay addons dependent on stable services/API contracts rather than importing one another's mutable registries, and treating the pack builder as a deterministic compiler rather than a ZIP utility.

These are planning constraints and design direction, not a claim that all proposed modules/services already exist in main.

Compatibility policy

The roadmap's most important rule is already visible in implementation: compatibility must be explicit. 1.21.4 no longer claims unvalidated future versions, and Minecraft/Paper 26.2 received a dedicated adapter, Java target, pack profile and smoke row. Future releases should follow that pattern.

Documentation rule for future milestones

When a roadmap item is merged, move its behavioural contract into dedicated reference pages and remove it from the “not implemented” list. Do not make this roadmap page the only documentation for a completed subsystem.