Update missing docs version

docs/reference/changelog.md

@@ -9,9 +9,9 @@ This document tracks all notable changes, new features, breaking changes, and im
 
 ## Current Release
 
-### [v0.3.0] - 2025-07-31
+### [v0.4.0] - 2025-11-17
 
-**[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.3.0)**
+**[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.4.0)**
 
 ---
 
@@ -21,6 +21,10 @@ This document tracks all notable changes, new features, breaking changes, and im
 
 **[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.2.0)**
 
+### [v0.3.0] - 2025-07-31
+
+**[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.3.0)**
+
 ---
 
 ## Upcoming Releases and Release Schedule

docusaurus.config.ts

@@ -43,10 +43,14 @@ 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
+          lastVersion: 'v0.4.x', // TODO: Update this when v0.5.x is released to mark it as the latest version
           versions: {
+            'v0.5.x': {
+              label: 'v0.5.x (edge)',
+              banner: 'none',
+            },
             'v0.4.x': {
-              label: 'v0.4.x (edge)',
+              label: 'v0.4.x',
               banner: 'none',
             },
             'v0.3.x': {
@@ -86,9 +90,9 @@ const config: Config = {
 
   themeConfig: {
     announcementBar: {
-      id: 'release_v0_3_1',
+      id: 'release_v0_4_0',
       content:
-        '🎉️ OpenChoreo <a target="_blank" rel="noopener noreferrer" href="https://github.com/openchoreo/openchoreo/releases/tag/v0.3.2">v0.3.2</a> is released! 🎉️',
+        '🎉️ OpenChoreo <a target="_blank" rel="noopener noreferrer" href="https://github.com/openchoreo/openchoreo/releases/tag/v0.4.0">v0.4.0</a> is released! 🎉️',
       isCloseable: true,
     },
     algolia: {

versioned_docs/version-v0.4.x/reference/changelog.md

@@ -9,9 +9,9 @@ This document tracks all notable changes, new features, breaking changes, and im
 
 ## Current Release
 
-### [v0.3.0] - 2025-07-31
+### [v0.4.0] - 2025-11-17
 
-**[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.3.0)**
+**[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.4.0)**
 
 ---
 
@@ -21,6 +21,10 @@ This document tracks all notable changes, new features, breaking changes, and im
 
 **[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.2.0)**
 
+### [v0.3.0] - 2025-07-31
+
+**[📋 View Full Release Notes](https://github.com/openchoreo/openchoreo/releases/tag/v0.3.0)**
+
 ---
 
 ## Upcoming Releases and Release Schedule

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

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

versioned_docs/version-v0.5.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.5.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.
+
+