Roadmap

Current products

DaisyCore: the runtime/platform product
DaisySeries: the parser/reference utility product
DaisyConfig: the typed YAML, managed lifecycle, and module bundle product

Current ecosystem priority

The current DaisySuite priority is quality, boundary discipline, and staged next-major planning:

keep only repeated real-use features
harden what already solves repeated plugin pain
improve docs, migration, examples, and release truth
keep product boundaries explicit
avoid breadth that exists only to claim coverage

That work comes before the next new Daisy-owned library.

Current shipped baselines

DaisyCore: 0.1.0
DaisySeries: 0.4.0
DaisyConfig: 0.2.0

Next staged majors

The next-major roadmap is staged, not synchronized:

DaisyConfig 2.0
DaisySeries 2.0
DaisyCore 2.0

This order is deliberate. DaisyCore just completed its first stable-release hardening pass, DaisySeries is intentionally gated on justified parser families, and DaisyConfig is the strongest next leverage point because it already ships meaningful capability but still needs stronger proof, examples, and adoption clarity.

DaisyConfig 2.0

DaisyConfig currently focuses on:

typed YAML mapping
managed YAML lifecycle
module bundles
DaisySeries-backed codecs
DaisyCore-friendly text bridging

See the config docs: DaisyConfig Overview

Next-major target

The next major target is a DaisyConfig proof and productization pass.

Why:

managed YAML, migrations, and module bundles are already valuable but still under-proven publicly
DaisyConfig is the strongest suite candidate for a sharper “obvious default” story next
better DaisyConfig proof improves the full-stack story for both DaisySeries and DaisyCore

Expected focus:

stronger managed-YAML documentation
stronger module-bundle examples
cleaner migration guidance from plugin-local config services
tighter text-bridge ownership story

DaisySeries 2.0

DaisySeries currently ships:

materials
sounds
item flags
enchantments
potions
biomes
villager professions
attributes
entity types
game modes
difficulties
block faces
damage causes
operations
pattern types
particles
statistics

DaisySeries growth is now intentionally gated. New parser families should only land when repeated modern plugin use clearly justifies them.

See the utility docs: DaisySeries Overview

Next-major target

The DaisySeries next-major line should formalize the inclusion gate and only approve a new parser family if it clearly beats the value of staying smaller.

Expected focus:

explicit classification of shipped, tracked, and rejected families
docs and dictionary consistency across the current module family
cross-product examples with DaisyConfig and DaisyCore
a real go/no-go decision on tracked candidates like world types, villager types, and map cursor types

DaisyCore 2.0

DaisyCore currently focuses on:

platform bootstrap
commands
menus
shared text and placeholders
items
sidebars
tablists

See the platform docs: DaisyCore Overview

Next-major target

The DaisyCore next-major line should wait until the lower config/parser story is clearer, then focus only on repeated runtime pain that genuinely deserves expansion beyond 0.1.0.

Expected focus:

stronger full-stack integration story with DaisyConfig and DaisySeries
runtime cohesion where local plugin glue still repeats
selective API improvements, not feature inflation
the same one-library public story, still bounded by honest scope

Future libraries

No new Daisy-owned library should start before these staged major lines are settled.

Tracked future candidates remain:

DaisyData for persistence, repositories, caches, and player data lifecycle
DaisyEffects for particles, sounds, titles, action bars, and display-effect composition

The gate before starting either one is still simple:

the current three shipped products are coherent and release-credible
the staged next-major contracts are settled
the next library clearly solves repeated modern Paper pain
the feature fits a clean product boundary
the value beats simply polishing what already exists