====== 7.6 Configuration File Naming ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:07-naming-and-file-conventions:start | Return to Naming and File Conventions ]] [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] file names should identify the configured subject, the environment or profile where relevant, and the file format. A Configuration file should make clear whether it configures a [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]], a [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] participant, a QoS profile, logging behaviour, a container runtime, a demonstration setup, or a local override. Representative Configuration names include: * ''node-registry.yaml'' * ''control-plane-qos.xml'' * ''logging-baseline.yaml'' * ''demo-phase0.yaml'' * ''fx-reference-node.yaml'' The team should distinguish the shared [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] Configuration from the local developer Configuration. Shared Baseline Configuration may enter Git. Local developer overrides should use a clear suffix or location, such as: * ''*.local.yaml'' * ''config/local/'' The [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] should normally ignore local override files unless the team explicitly decides to version a sample. Sample Configuration files should use clear names such as: * ''node.local.sample.yaml'' * ''environment.local.sample'' Configuration names should not encode secrets, personal machine names, developer initials, or local paths. If Configuration differs across environments, the team should use documented profiles, templates, or environment variables rather than creating undocumented personal files. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.