Add v0.4.x versioned documentation

Create versioned documentation for OpenChoreo v0.4.x release, including all updated guides, API references, and configuration. Set v0.3.x as the current latest version until v0.5.x is released.

Author: Mirage20

docusaurus.config.ts

@@ -43,6 +43,7 @@ const config: Config = {
       'classic',
       {
         docs: {
+          lastVersion: 'v0.3.x', // TODO: Remove this when v0.5.x is released to mark it as the latest version
           sidebarPath: './sidebars.ts',
           showLastUpdateAuthor: true,
           showLastUpdateTime: true,

versioned_docs/version-v0.4.x/_constants.mdx

@@ -0,0 +1,7 @@
+[//]  # (This file stores the constants used across the documentation.)
+
+export const versions = {
+    dockerTag: 'v0.4.0',
+    githubRef: 'release-v0.4', // Used for the GitHub Raw URL references. Example: main, latest, v0.1.0
+    helmChart: '0.4.0',
+};

versioned_docs/version-v0.4.x/concepts/developer-abstractions.md

@@ -0,0 +1,103 @@
+---
+title: Developer Abstractions
+description: Developer abstractions for building and running applications
+---
+
+# Developer Abstractions
+
+Developer abstractions in OpenChoreo enable teams to build, deploy, and operate cloud-native applications without
+managing infrastructure complexity. These abstractions provide a declarative model for expressing application
+architecture, dependencies, and operational requirements while the platform handles the underlying Kubernetes resources,
+networking, and security configurations automatically.
+
+## Project
+
+A **Project** represents a bounded context in Domain-Driven Design terms - a cohesive collection of components that
+together implement a specific business capability or application domain. It serves as the primary organizational unit
+for developers, defining clear boundaries for code ownership, deployment coordination, and operational responsibility.
+
+Projects establish both logical and physical boundaries in the platform. Logically, they group related components that
+share common business logic, data models, and team ownership. Physically, they translate into isolated deployment units
+with dedicated namespaces, network boundaries, and security policies. This alignment between organizational structure
+and technical architecture enables teams to work autonomously while maintaining clear integration points with other
+projects.
+
+The project boundary also defines the scope for internal communication and shared resources. Components within a project
+can communicate freely with each other. This locality principle reduces complexity for
+developers while maintaining security and isolation between different application domains.
+
+## Component
+
+A **Component** represents a deployable unit of software - the fundamental building block of applications in OpenChoreo.
+Each component encapsulates a specific piece of functionality, whether it's a microservice handling business logic, a
+web application serving user interfaces, or a background job processing data.
+
+Components provide the connection between source code and running applications. They define how code is built, what
+resources it requires, and how it should be deployed. This abstraction allows developers to focus on application logic
+while the platform handles the complexities of containerization, orchestration, and lifecycle management.
+
+## Component Types
+
+OpenChoreo provides specialized component types that represent common application patterns, each with its own
+operational characteristics and platform integrations.
+
+### Service
+
+A **Service** component represents backend applications that expose APIs or handle business logic. Services are the
+workhorses of cloud-native applications, processing requests, managing data, and integrating with other systems. The
+platform understands that services need stable network identities, load balancing, and API management capabilities.
+
+Services can expose multiple protocols including HTTP, gRPC, and TCP, with the platform handling the appropriate 
+routing and load balancing for each protocol type.
+
+### WebApplication
+
+A **WebApplication** component represents frontend applications that serve user interfaces. These might be single-page
+applications, server-side rendered websites, or static content. The platform recognizes that web applications have
+different operational requirements than backend services and provides appropriate deployment patterns through the 
+WebApplicationClass.
+
+### ScheduledTask
+
+A **ScheduledTask** component represents batch jobs, cron jobs, and other time-based workloads. Unlike continuously
+running services, scheduled tasks execute at specific times or intervals, complete their work, and terminate. 
+ScheduledTasks are configured with cron expressions to define when they should run, and the platform handles the 
+scheduling through the ScheduledTaskClass and Kubernetes CronJob resources.
+
+## Workload
+
+A **Workload** defines the runtime contract of a component - specifying what the component needs to run. The workload 
+focuses on application requirements rather than infrastructure details, which are handled by the platform through Classes.
+
+Each component has one workload that describes its runtime needs through several key specifications:
+
+**Containers** define the container images to deploy, along with their commands, arguments, and environment variables. 
+This tells the platform what code to run and how to configure it.
+
+**Endpoints** specify the network interfaces that the component exposes - the ports and protocols it listens on. Each 
+endpoint declares its type (HTTP, gRPC, TCP, etc.) and port number. These definitions tell the platform what network 
+services the component provides, enabling automatic service creation and network policy generation.
+
+**Connections** declare the component's dependencies on other services, whether internal to the platform or external 
+third-party services. Each connection specifies how to inject service information into the component through environment 
+variables. This enables the platform to manage service discovery, configure network policies, and track dependencies.
+
+This declarative specification can be generated from configuration files in the source repository or applied directly 
+to the cluster. The separation between workload (what the application needs) and classes (how the platform provides it) 
+enables platform teams to control infrastructure policies while developers focus on application requirements. Resource 
+limits, scaling parameters, and operational policies come from the ServiceClass or WebApplicationClass, while the 
+workload simply declares what the application needs to function.
+
+## Build
+
+A **Build** represents the process of transforming source code into deployable artifacts. It captures the build
+configuration, tracks build execution, and manages the resulting container images. The build abstraction provides a
+consistent interface for different build strategies while handling the complexities of secure, reproducible builds.
+
+Builds in OpenChoreo are first-class resources that can be monitored, audited, and managed independently of deployments.
+This separation enables practices like building once and deploying many times, pre-building images for faster
+deployments, and maintaining clear traceability from source code to running containers.
+
+The platform supports multiple build strategies to accommodate different technology stacks and organizational
+preferences. Whether using Cloud Native Buildpacks for automatic, opinionated builds or custom Dockerfiles for complete
+control, the build abstraction provides a consistent operational model.

versioned_docs/version-v0.4.x/concepts/platform-abstractions.md

@@ -0,0 +1,142 @@
+---
+title: Platform Abstractions
+description: Platform abstractions for managing infrastructure
+---
+
+# Platform Abstractions
+
+Platform abstractions in OpenChoreo provide the foundational infrastructure layer that platform engineers use to build
+and manage Internal Developer Platforms. These abstractions establish organizational boundaries, manage infrastructure
+resources, and define the operational policies that enable developer self-service while maintaining security and
+compliance.
+
+## Organization
+
+The **Organization** represents the highest level of tenancy in OpenChoreo, serving as the root container for all
+platform resources. It establishes the fundamental isolation boundary between different business units, teams, or
+customers in a multi-tenant platform.
+
+Organizations provide complete resource isolation through dedicated Kubernetes namespaces, ensuring that resources,
+configurations, and workloads from different organizations never interact. This isolation extends beyond simple
+namespace separation to include network policies, RBAC rules, and resource quotas, creating a secure multi-tenant
+environment.
+
+Each organization maintains its own set of platform resources, application resources, and runtime configurations. This
+hierarchical structure enables platform teams to manage multiple independent tenants on the same OpenChoreo
+installation, each with their own governance policies, resource limits, and operational procedures.
+
+## Infrastructure Planes
+
+OpenChoreo separates infrastructure concerns into specialized planes, each serving a distinct purpose in the platform
+architecture. This separation enables independent scaling, security isolation, and operational management of different
+platform functions.
+
+### DataPlane
+
+A **DataPlane** represents a Kubernetes cluster where application workloads run. It abstracts the complexity of cluster
+management, providing a unified interface for deploying applications across multiple clusters regardless of their
+location or underlying infrastructure.
+
+DataPlanes encapsulate all the configuration needed to connect to and manage a Kubernetes cluster, including connection
+credentials, TLS certificates, and cluster-specific settings. They enable platform teams to register multiple clusters -
+whether on-premises, in public clouds, or at edge locations - and manage them through a single control plane.
+
+Each DataPlane can host multiple environments and projects, with OpenChoreo managing the creation of namespaces, network
+policies, and other cluster resources automatically. This abstraction allows platform teams to treat clusters as
+interchangeable infrastructure resources, enabling strategies like geographic distribution, compliance-based placement,
+and disaster recovery.
+
+### BuildPlane
+
+A **BuildPlane** provides dedicated infrastructure for executing continuous integration and build workloads. By
+separating build operations from runtime workloads, BuildPlanes ensure that resource-intensive compilation and testing
+processes don't impact production applications.
+
+BuildPlanes integrate with Argo Workflows to provide a scalable, Kubernetes-native CI/CD execution environment. They
+handle the complete build lifecycle, from source code retrieval through compilation, testing, and container image
+creation. This separation also provides security benefits, isolating potentially untrusted build processes from
+production environments.
+
+Platform engineers configure BuildPlanes with the necessary tools, credentials, and policies for building applications.
+This includes container registry credentials, build tool configurations, and security scanning policies. BuildPlanes can
+be scaled independently based on build demand and can be distributed geographically to reduce latency for development
+teams.
+
+### Observability Plane
+
+The **Observability Plane** provides centralized logging infrastructure for the entire platform. It collects and
+aggregates logs from all other planes - Control, Data, and Build - providing a unified view of platform operations and
+application behavior.
+
+Built on OpenSearch, the Observability Plane offers full-text search capabilities and log retention management. The
+Observer API provides authenticated access to log data, enabling integration with external monitoring tools and
+dashboards. Unlike other planes, the Observability Plane has no custom resources to manage - it operates independently
+after initial setup, receiving log streams from Fluentbit agents deployed across the platform.
+
+Platform engineers configure the Observability Plane once during initial setup, establishing log collection pipelines,
+retention policies, and access controls. This centralized approach ensures that all platform activity is auditable and
+debuggable while maintaining security boundaries between organizations.
+
+## Environment
+
+An **Environment** represents a stage in the software delivery lifecycle, such as development, staging, or production.
+Environments provide the context for deploying and running applications, defining the policies, configurations, and
+constraints that apply to workloads in that stage.
+
+Environments are not just labels or namespaces - they are first-class abstractions that define where applications 
+should be deployed (which DataPlane) and serve as targets for deployment pipelines. This abstraction enables platform 
+teams to organize different stages of the delivery pipeline.
+
+Each environment represents a distinct deployment target. Development environments might target smaller clusters or 
+shared infrastructure, while production environments target dedicated, high-availability clusters. The Environment 
+resource primarily defines the mapping to infrastructure (DataPlane) and serves as a reference point for deployments 
+and promotion workflows.
+
+## DeploymentPipeline
+
+A **DeploymentPipeline** defines the allowed progression paths for applications moving through environments. It
+represents the organization's software delivery process as a declarative configuration, encoding promotion rules,
+approval requirements, and quality gates.
+
+DeploymentPipelines go beyond simple environment ordering to define complex promotion topologies. They can specify
+parallel paths for different types of releases and conditional progressions based on application characteristics. 
+This flexibility allows organizations to implement sophisticated delivery strategies while maintaining governance and 
+control.
+
+The pipeline abstraction also serves as an integration point for organizational processes. Manual approval gates can be
+configured for sensitive environments, automated testing can be triggered at promotion boundaries, and compliance checks
+can be enforced before production deployment. This ensures that all applications follow organizational standards
+regardless of which team develops them.
+
+## Class System
+
+OpenChoreo implements the standard Kubernetes Class pattern, similar to GatewayClass or StorageClass, enabling platform
+engineers to define platform-level abstractions that developers consume through their applications.
+
+### The Class Pattern
+
+Classes are platform-level resources that encode organizational standards, best practices, and governance policies.
+Platform engineers create Classes for different workload types - ServiceClass for backend services, WebApplicationClass
+for frontend applications, and ScheduledTaskClass for batch jobs. Each Class defines the platform standards that
+applications must follow when claiming these resources.
+
+Just as GatewayClass defines infrastructure capabilities that Gateway resources consume, or StorageClass defines how
+storage should be provisioned when a PersistentVolumeClaim is created, ServiceClass defines how services should be
+deployed when developers create Service resources. This pattern provides a clean separation between platform
+capabilities (defined by platform engineers) and application requirements (expressed by developers).
+
+### Class Consumption
+
+When developers create application resources like Service or WebApplication, they reference the appropriate Class,
+similar to how a PersistentVolumeClaim references a StorageClass. The platform uses the Class definition to provision
+the actual workload with the correct configuration, policies, and governance rules.
+
+Environment-specific Bindings act as the instantiation of this claim in a specific environment. While the Service
+resource expresses the developer's intent and references a ServiceClass, the ServiceBinding represents the actual
+deployment of that service in a particular environment with environment-specific overrides.
+
+This consumption model balances standardization with flexibility. Platform teams maintain control over critical
+configurations through Classes while developers express their requirements through simple resource definitions. The
+platform handles the complex mapping between developer intent and infrastructure reality.
+
+