• 3.0.0-alpha.1+1.21.10 7c086eb190

    v3.0.0-alpha.1 (Minecraft 1.21.10)
    All checks were successful
    Build / build (push) Successful in 2m41s
    Stable

    Greencow released this 2026-01-20 19:58:54 +00:00 | 1 commits to 1.21.11 since this release

    Build Specific Changes

    • Initial 3.0.0 Alpha Release. Read below for every change in this release.

    Full Changelog

    This is the v3.0.0 Release of Greenhouse Config, which is additionally the first release to be hosted on the Greenhouse Forgejo instead of GitHub.
    Greenhouse Config has been rewritten from the ground up for a better experience.

    Roadmap

    • Alpha Versions may break API at any time. These should be considered unstable and not production ready. These may be incomplete with missing javadocs and implementation.
    • Beta Versions will have a stable API, but may make small breaking changes if something does not work. These versions are also lacking some features such as backwards compatibility with the old API.
    • Release 3.0.0 will be considered feature complete, but new features and minor breaking changes may come with future Minecraft versions such as 26.1.x and above.

    Changes

    • Updated mod icon and description.
    • All package structure has been reworked to use lgbt.greenhouse.config.api.v3 for API, and lgbt.greenhouse.config.impl for impl.
    • Greenhouse Config now operates off a builder system.
      • Methods to build configs may be found in GreenhouseConfigHolder related interfaces.
      • Raw RecordCodecBuilder/StreamCodec/DataFixerUpperBuilder based operations are still supported via any Greenhouse Config Holder Builder. These are generally less encouraged in comparison to the builder.
    • Added GreenhouseInheritedConfigHolder. This can be used to inherit values from a Greenhouse Config Holder or Greenhouse Config Holder Builder meant for a common client to a specifically sided environment such as the client and the server, as well as allowing for adding new values on top of these values.
      • The SPLIT side definition of the old config has been removed from the V3 API to better compatibility with split source-set based environments.
    • Added GreenhouseConfigDataFixerBuilder, which can be used to create data fixers for your config to update between different schema versions.
    • GreenhouseConfigDataFixerBuilder now supports defining previous config formats, these will be detected based on the config's schema version and will rewrite the file to the new format when applicable.
    • LateHolder and LateHolderSet have been rewritten to better integrate into GreenhouseConfigHolderBuilder. The Late interface has been removed.
    • Included built-in data fixes for ease of use when fixing config values.
      • These are GreenhouseConfigRelocateFieldsFix, GreenhouseConfigRemoveFieldsFix, and GreenhouseConfigSetFieldsFix and are found within the lgbt.greenhouse.config.v3.dfu.fix package.
    • Schema versions are now stored within a hidden .greenhouse_config_meta folder instead of the config's file attributes.
      • Configs with no schema version will be treated as V0, but will only ever be fixed in this case if the config has any errors.
      • A fallback for the file attribute is included to correctly load configs made with older Greenhouse Config versions.
    • Events within Greenhouse Config now use Yumi for a better loader agnostic experience.
      • All events are within lgbt.greenhouse.config.api.v3.GreenhouseConfigEvents.
      • Greenhouse Config specific phases are within lgbt.greenhouse.config.api.v3.GreenhouseConfigEventPhases.
    • Swapped config reading/writing to use included libraries within the Polyamory Project.
      • You will no longer need to depend on a separate project for your specific language.
      • Polyamory only supports JSONC within this current release.
    • Removed Night Config support. Removing TOML, HOCON and YAML language support.
      • TOML will be re-added before release whenever I'm more ready to write it.
      • YAML might be re-added if there's enough demand. If so, it'll be a low priority change.
      • HOCON will not be re-added due to being more of a liability and generally having low demand.
    • The implementation has been entirely rewritten from the ground up. It has been tested in a lot more conditions and should generally be a lot more stable and less messy.
    Downloads