docs: clarify BIND9 9.20 branch strategy

docs/BIND9_9.20_SUPPORT.md

@@ -2,53 +2,53 @@
 
 ## Overview
 
-This document describes the ansible-bind9-role implementation for BIND9 9.20+ support through the `feature/bind9-20-support` branch.
+This document describes the ansible-bind9-role strategy for BIND9 9.20+ support through a dedicated version branch.
+
+The current implementation uses branch-level compatibility boundaries instead of runtime version detection. The main branch targets BIND9 9.18.x LTS, while the 9.20 branch targets BIND9 9.20+ feature releases.
 
 ## Architecture
 
-### Multi-Version Support Strategy
+### Branch-Based Support Strategy
 
-The role supports multiple BIND9 versions using:
+The role uses branch-only support boundaries:
 
-1. **Runtime Version Detection**: BIND9 version is detected at runtime and stored in the `bind9_version` fact
-2. **Template Conditionals**: Jinja2 conditionals in templates apply version-specific configurations
-3. **Separate Branches**: Different BIND9 feature release series are maintained on separate branches
-   - `main`: BIND9 9.18.x (LTS) - Production stable
-   - `9.20`: BIND9 9.20+ (feature releases) - New features and modern approach
+1. `main` branch: BIND9 9.18.x LTS support for production-stable deployments.
+2. `9.20` branch: BIND9 9.20+ feature-release support with version-specific templates, grammar data, tests, and documentation.
+
+The role does not currently detect BIND9 versions at runtime and does not use runtime version conditionals in templates. Each branch is expected to be tested against the BIND9 series it supports.
+
+This approach is preferred because:
+
+- compatibility boundaries are clear for users and maintainers;
+- templates avoid cross-version conditional complexity;
+- each branch can evolve with the grammar and package behavior of its target BIND9 series;
+- generated configuration does not silently change based on the installed package version.
 
 ### Branch Structure
 
 ```
-main                          # BIND9 9.18.x LTS (stable)
+main                    # BIND9 9.18.x LTS support
 │
-└─ 9.20                       # BIND9 9.20+ feature releases
-   ├─ feature/bind9-20-support  # Current development branch
-   └─ (will merge to 9.20 after testing)
+└─ 9.20                 # BIND9 9.20+ feature-release support
+   └─ feature/*          # Short-lived feature branches targeting 9.20
 ```
 
 ## Implementation Details
 
-### 1. Version Detection (tasks/main.yml)
+### 1. Task Flow
 
-```yaml
-- name: Detect BIND9 version at runtime
-  ansible.builtin.command:
-    cmd: named -v
-  register: _bind9_version_output
-  changed_when: false
+1. Install the configured BIND9 packages from `bind9_packages`.
+2. Ensure backup and logging directories exist when enabled or configured.
+3. Render configured BIND9 files through `named.conf.generator.j2`.
+4. Validate the generated configuration with `named-checkconf -z`.
+5. Restore backed-up configuration files if validation fails.
+6. Start and enable the `named` service.
 
-- name: Set bind9_version fact
-  ansible.builtin.set_fact:
-    bind9_version: "{{ _bind9_version_output.stdout | regex_search('BIND (\\S+)', '\\1') | first }}"
-```
+There is no runtime `bind9_version` fact in this flow.
 
 ### 2. Meta/Argument Specs Updates
 
-The `meta/argument_specs.yml` has been updated to:
-
-- Document BIND9 9.20+ support alongside 9.18.x
-- Add `bind9_version` variable documentation (read-only, auto-detected)
-- Clarify version-specific behavior
+The `meta/argument_specs.yml` file documents the public role inputs for the current branch. It must not document runtime-only variables that the role does not set or consume.
 
 ### 3. Molecule Testing
 
@@ -67,7 +67,7 @@ Two molecule scenarios are now available:
 
 ### 4. Template Version Compatibility
 
-Templates have been audited for BIND9 9.20 compatibility. The primary template files include:
+Templates in each version branch should be audited for the BIND9 series targeted by that branch. The primary template files include:
 
 - `named.conf.options.j2` - Global options block
 - `named.conf.zone.j2` - Zone definitions
@@ -77,10 +77,10 @@ Templates have been audited for BIND9 9.20 compatibility. The primary template f
 
 ### 5. Deprecated Options Handling
 
-BIND9 9.20 removes 44 options from 9.18. The role handles this through:
+BIND9 9.20 removes 44 options from 9.18. The 9.20 branch should handle this through:
 
 1. **Documentation**: Each deprecated option is documented in BIND9_MIGRATION_GUIDE.md
-2. **Conditional Removal**: Templates check version and exclude removed options
+2. **Branch-specific templates**: Templates on the 9.20 branch omit removed options
 3. **Migration Path**: BIND9_MIGRATION_GUIDE.md provides alternatives for each removed option
 
 ## Critical BIND9 9.20 Changes
@@ -204,6 +204,8 @@ Users upgrading from 9.18 to 9.20 should:
 
 - [ ] Automated configuration migration tool
 - [ ] Deprecation warnings in role output
+- [ ] Runtime version detection if branch-per-version maintenance becomes insufficient
+- [ ] Template conditionals only if a future design intentionally supports multiple BIND9 series from one branch
 - [ ] 9.21+ preparation when available
 - [ ] Performance tuning for 9.20 features
 - [ ] DNS-over-HTTPS (DoH) support
@@ -214,9 +216,9 @@ Users upgrading from 9.18 to 9.20 should:
 - [ISC BIND9 Website](https://www.isc.org/bind/)
 - [BIND9 9.20 Release Notes](https://www.isc.org/download/news/)
 - [BIND9 Documentation](https://bind9.readthedocs.io/)
-- [BIND9 Version Differences](../../docs/BIND_VERSION_DIFFERENCES.md)
-- [BIND9 Migration Guide](../../docs/BIND9_MIGRATION_GUIDE.md)
-- [VERSION_SUPPORT.md](../../docs/VERSION_SUPPORT.md)
+- [BIND9 Version Differences](BIND_VERSION_DIFFERENCES.md)
+- [BIND9 Migration Guide](BIND9_MIGRATION_GUIDE.md)
+- [VERSION_SUPPORT.md](VERSION_SUPPORT.md)
 
 ## Support