Skip to content

Documentation: Introduce Versioned Command Documentation Structure #25

@utkarsh232005

Description

@utkarsh232005

Documentation Enhancement: Introduce Versioned Command Documentation Structure

Summary

The current version of KDM lacks structured and complete documentation for available commands and their usage. This makes it difficult for users to understand features, workflows, configuration methods, and command behavior—especially as the project continues to evolve rapidly.

To improve developer experience and maintain long-term scalability, detailed version-based documentation should be introduced for every command and feature in KDM.


Problem

At the moment:

  • There is no centralized documentation structure
  • Commands are not properly documented
  • Users do not have clear usage references
  • Feature discoverability is low
  • Changes between versions are difficult to track
  • New users struggle to understand workflows and command behavior
  • Documentation does not reflect the currently installed version of KDM

As the CLI grows, maintaining unstructured documentation will become increasingly difficult.


Proposed Solution

Create a dedicated versioned documentation system for KDM using a structured folder hierarchy.

Example structure:

docs/
└── v2.1.2/
    ├── config/
    │   ├── setup.md
    │   ├── show.md
    │   ├── reset.md
    │   └── set.md
    │
    ├── runner/
    │   ├── start.md
    │   ├── stop.md
    │   └── status.md
    │
    ├── docker/
    ├── kubernetes/
    ├── monitoring/
    └── README.md

Documentation Requirements

Each command documentation file should include:

1. Command Overview

  • Purpose of the command
  • What the command does
  • Supported environments/services

2. Syntax

Example:

kdm config setup

3. Parameters & Options

Option Description
--help Display help information
--verbose Enable detailed logs

4. Example Usage

Provide practical real-world examples.

Example:

kdm runner start

5. Expected Output

Document sample outputs for better understanding.


6. Use Cases

Explain when and why users should use the command.


7. Common Errors

Document known issues and troubleshooting steps.

Example:

  • Invalid credentials
  • Missing Docker daemon
  • Kubernetes context not found

8. Version Information

Every documentation page should clearly mention:

Version: v2.1.2

This ensures users always know which CLI version the documentation belongs to.


Suggested Improvements

  • Add auto-generated command help sections
  • Include screenshots/GIFs for interactive flows
  • Add migration notes between versions
  • Include deprecated command notices
  • Add quick-start guides
  • Add beginner-friendly onboarding docs

Benefits

  • Better onboarding experience
  • Easier maintenance for future releases
  • Improved developer productivity
  • Reduced confusion across versions
  • Easier contribution process for open-source contributors
  • Professional project structure
  • Scalable documentation architecture

Expected Outcome

KDM should have a fully structured and versioned documentation system where every command is documented clearly with:

  • Usage
  • Examples
  • Parameters
  • Troubleshooting
  • Use cases
  • Version references

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions