Skip to main content

SKU Naming Conventions

Detailed specification of the EGI SKU format and naming rules.

Format Structure​

X.Y.Z.TYPE.PLATFORM.YYYYMMDD

Component 1: Semantic Version (X.Y.Z)​

The semantic version follows standard semver conventions.

Format: MAJOR.MINOR.PATCH

  • MAJOR (X) - Breaking changes or major rewrites

    • Increment when you make incompatible API changes
    • Reset MINOR and PATCH to 0
    • Example: 1.0.0 → 2.0.0

  • MINOR (Y) - New features (backward compatible)

    • Increment when you add functionality in a backward-compatible manner
    • Reset PATCH to 0
    • Example: 1.0.0 → 1.1.0

  • PATCH (Z) - Bug fixes and patches

    • Increment for backward-compatible bug fixes
    • Example: 1.1.0 → 1.1.1

Rules:

  • All components must be non-negative integers
  • No leading zeros (except for 0 itself)
  • Start at 1.0.0 for first production release
  • Use 0.x.x for pre-release/beta versions

Component 2: System Type (TYPE)​

A standardized code identifying the system's purpose and architecture.

Format: Uppercase letters (2-3 characters typical)

Examples:

  • API - REST/GraphQL API service
  • BOT - Background worker or automation bot
  • RAG - RAG (Retrieval-Augmented Generation) system
  • WA - Web application (frontend)
  • SDK - Software development kit

Rules:

  • Must use codes from the official system types list
  • Case-sensitive (always uppercase)
  • No custom codes without approval
  • See System Types for complete list

Component 3: Platform (PLATFORM)​

A standardized code identifying the deployment platform.

Format: Uppercase letters (2-4 characters typical)

Examples:

  • EKS - AWS Elastic Kubernetes Service
  • GKE - Google Kubernetes Engine
  • LM - AWS Lambda
  • VE - Vercel
  • CF - Cloudflare Workers/Pages

Rules:

  • Must use codes from the official platforms list
  • Case-sensitive (always uppercase)
  • Choose the most specific code available
  • See Platform Identifiers for complete list

Component 4: Build Date (YYYYMMDD)​

The date the build/release was created.

Format: 8 digits in ISO date format

Examples:

  • 20250127 - January 27, 2025
  • 20250201 - February 1, 2025

Rules:

  • Must be a valid date
  • Must be in YYYYMMDD format (no separators)
  • Should reflect the actual build date, not deployment date
  • Should be automatically generated in CI/CD

Complete Examples​

Basic API Service​

1.0.0.API.EKS.20250127
  • Version: 1.0.0 (first production release)
  • Type: API (REST/GraphQL service)
  • Platform: EKS (AWS Kubernetes)
  • Built: January 27, 2025

Background Worker​

2.5.1.BOT.GKE.20250115
  • Version: 2.5.1 (patch on 2.5 series)
  • Type: BOT (background worker)
  • Platform: GKE (Google Kubernetes)
  • Built: January 15, 2025

RAG System​

1.2.0.RAG.LM.20250201
  • Version: 1.2.0 (minor update)
  • Type: RAG (retrieval-augmented generation)
  • Platform: LM (AWS Lambda)
  • Built: February 1, 2025

Web Application​

3.0.0.WA.VE.20250110
  • Version: 3.0.0 (major update)
  • Type: WA (web application)
  • Platform: VE (Vercel)
  • Built: January 10, 2025

Validation Rules​

A valid SKU must:

  1. Have exactly 6 components separated by dots
  2. Use valid semantic version format (X.Y.Z)
  3. Use an approved TYPE code
  4. Use an approved PLATFORM code
  5. Have a valid 8-digit date (YYYYMMDD)
  6. Contain no whitespace or special characters (except dots)

Best Practices​

Version Incrementing​

Increment MAJOR when:

  • Breaking API changes
  • Major architectural rewrites
  • Removal of deprecated features
  • Incompatible with previous versions

Increment MINOR when:

  • New features added (backward compatible)
  • Significant functionality enhancements
  • New APIs or endpoints added
  • Deprecating features (but still functional)

Increment PATCH when:

  • Bug fixes
  • Security patches
  • Performance improvements
  • Documentation updates

Build Date Usage​

DO:

  • Generate build date automatically in CI/CD
  • Use the actual build/compile date
  • Keep the same date for the same build across environments

DON'T:

  • Use deployment date (when it's pushed to production)
  • Manually set the date
  • Change the date when promoting between environments

Platform Selection​

DO:

  • Use the most specific platform code available
  • Use the same code for all instances in the same environment
  • Document any platform-specific variations

DON'T:

  • Mix platform codes within a single environment
  • Use generic codes (AWS, GCP) when specific codes exist (EKS, GKE)
  • Create custom platform codes without approval

Multi-Platform Deployments​

If deploying the same version to multiple platforms, use separate SKUs:

1.0.0.API.EKS.20250127    # AWS Kubernetes
1.0.0.API.GKE.20250127    # Google Kubernetes
1.0.0.API.LM.20250127     # AWS Lambda

Note:

  • Same version number (1.0.0)
  • Same build date (20250127)
  • Different platform codes
  • Potentially different implementations optimized for each platform

Invalid SKU Examples​

1.0.0-API-EKS-20250127    # Wrong separator (should be dots)
1.0.API.EKS.20250127      # Missing patch version
1.0.0.api.eks.20250127    # Lowercase codes (should be uppercase)
1.0.0.API.EKS.2025-01-27  # Date with hyphens (should be YYYYMMDD)
1.0.0.API.EKS             # Missing build date
v1.0.0.API.EKS.20250127   # Extra prefix (remove "v")

See Also​