Config overhaul: add version and namespace to the configuration

[josecelano]

Parent issue: #401
Relates to: #401 (comment)

@da2ce7 proposed adding a version field to the configuration and also a namespace.

[torrust_tracker]
version = "1.0.0"

[torrust_tracker.logging]
log_level = "info"

{
  "torrust_tracker": {
    "version": "1.0.0",
    "logging": {
      "log_level": "info"
    }
  }
}

@da2ce7, is this the way you thought about including the namespace? I think it's a good idea because it allows merging different app configurations into a single TOML file (for example, a single Tracker and Index). However, it adds one level of indentation to the whole field.

[josecelano]

Hi @da2ce7 It seems docker compose has removed the version from the compose file. I understand the reasons, but I think it's still valid for our case.

• We are not planning to support more than one version simultaneously. If you update the tracker, you must update the config file (if there is a new major version).
• Even if it could be easier for users with no overrides to just continue using the same config file, for users with many overrides is helpful to know which version they were using to they can follow the CHANGELOG to update the config file.

I have not yet found the official reason, but this is what ChatGPT says:

ChatGPT

The "version" field was removed from the Docker Compose file specification starting with version 3.9 to streamline the configuration process and make it more flexible and less error-prone. Here are some key reasons for this change:

1. Simplification:

   • Removing the "version" field simplifies the Compose file format, making it easier to write and understand. Users no longer need to worry about specifying a particular version and can focus on defining their services.

2. Unified Specification:

   • By removing the version field, Docker Compose can support all features and options in a unified way. Previously, some features were available only in specific versions, which led to compatibility issues and confusion.

3. Forward Compatibility:

   • Without a version field, Compose files are inherently more forward-compatible. This means that users do not need to update their Compose files to specify a newer version if they want to use new features or improvements introduced in Docker Compose.

4. Dynamic Updates:

   • The removal of the version field allows the Docker Compose team to introduce new features and improvements more dynamically without the need to increment the version number and require users to update their files.

5. Consistency with Docker CLI:

   • This change brings more consistency with other Docker tools and the Docker CLI, which do not require a version field for their configuration files.

Overall, the removal of the "version" field in Docker Compose files reflects a move towards a more streamlined, flexible, and user-friendly approach to defining multi-container applications.

Other projects

Other important projects like Kubernetes, Terraform or Ansible.

[josecelano]

Hi @da2ce7, For the time being, I'm going to add only the version at the root level. For the namespace, I will wait until you confirm your idea.

version = "2"

[logging]
threshold = "info"

[core]
inactive_peer_cleanup_interval = 600
listed = false
private = false
tracker_usage_statistics = true

  [core.announce_policy]
  interval = 120
  interval_min = 120
  
  [core.database]
  driver = "Sqlite3"
  path = "./storage/tracker/lib/database/sqlite3.db"
  
  [core.net]
  external_ip = "0.0.0.0"
  on_reverse_proxy = false
  
  [core.tracker_policy]
  max_peer_timeout = 900
  persistent_torrent_completed_stat = false
  remove_peerless_torrents = true

[health_check_api]
bind_address = "127.0.0.1:1313"