Versioning

Dewy automatically detects the latest version of applications based on semantic versioning and achieves continuous deployment. It provides comprehensive version management functionality including pre-release version management.

Overview

Versioning in Dewy is the core functionality of pull-based deployment. Based on version information retrieved from registries, it automatically determines whether new versions are available by comparing with currently running versions, and executes automatic deployment as needed.

Key Features:

• Complete support for Semantic Versioning (SemVer)
• Flexible management of pre-release versions
• Support for multiple version formats (v1.2.3 / 1.2.3)
• Support for environment-specific version strategies

Semantic Versioning Basics

Version Format

Dewy supports version management compliant with Semantic Versioning 2.0.0.

Basic format:

MAJOR.MINOR.PATCH

Examples:

• 1.2.3 - Version 1.2.3
• v1.2.3 - Version 1.2.3 with v prefix
• 2.0.0 - Major version 2.0.0

Version Number Meanings

Pre-release Versions

Pre-release versions are versions intended for testing and evaluation before official release.

Format:

MAJOR.MINOR.PATCH-<pre-release-identifier>

Common patterns:

• v1.2.3-alpha - Alpha version (initial testing)
• v1.2.3-beta.1 - Beta version 1 (feature-complete testing)
• v1.2.3-rc.1 - Release candidate 1 (final verification)

Dewy's Version Detection Algorithm

Comparison Rules

Dewy implements its own semantic version comparison algorithm:

1. MAJOR version comparison - Compare numerically, prioritize larger
2. MINOR version comparison - When MAJOR is same, compare numerically
3. PATCH version comparison - When MAJOR.MINOR is same, compare numerically
4. Pre-release version handling:
   • Official version > Pre-release version
   • Pre-release versions are compared as strings

Latest Version Determination

For all version tags retrieved from registry:

// Pseudo code
func findLatest(versions []string, allowPreRelease bool) string {
    validVersions := filterValidSemVer(versions, allowPreRelease)
    return findMaxVersion(validVersions)
}

Processing flow:

1. Semantic version format validation
2. Filtering by pre-release settings
3. Numerical comparison and sorting
4. Maximum value selection

Registry-specific Version Management

GitHub Releases

Automatically detects versions from GitHub release tag names.

# Stable versions only (default)
dewy server --registry ghr://owner/repo

# Including pre-release versions
dewy server --registry "ghr://owner/repo?pre-release=true"

Grace period consideration:

AWS S3

Extracts versions from S3 object path structure.

Required path structure:

<path-prefix>/<semver>/<artifact>

Configuration example:

dewy server --registry "s3://ap-northeast-1/releases/myapp?pre-release=true"

S3 arrangement example:

releases/myapp/v1.2.4/myapp_linux_amd64.tar.gz
releases/myapp/v1.2.4/myapp_darwin_arm64.tar.gz
releases/myapp/v1.2.3/myapp_linux_amd64.tar.gz
releases/myapp/v1.2.3-rc.1/myapp_linux_amd64.tar.gz

Environment-specific Version Strategies

Production Environment

Recommended settings:

# Auto-deploy stable versions only
dewy server --registry ghr://company/myapp \
  --interval 300s \
  --log-format json -- /opt/myapp/current/myapp

Features:

• Exclude pre-release versions (pre-release=false)
• Longer polling intervals to reduce system load
• Prioritize monitoring ease with structured logs

Staging Environment

Recommended settings:

# Include pre-release versions for early testing
dewy server --registry "ghr://company/myapp?pre-release=true" \
  --interval 60s \
  --notifier "slack://staging-deploy?title=MyApp+Staging" \
  -- /opt/myapp/current/myapp

Features:

• Actively incorporate pre-release versions
• Short polling intervals for quick feedback
• Share with entire team through deployment notifications

Version Management Best Practices

Tagging Rules

Recommended tag naming conventions:

# Official releases
git tag v1.2.3
git tag v2.0.0

# Pre-releases
git tag v1.3.0-alpha
git tag v1.3.0-beta.1
git tag v1.3.0-rc.1

# Security fixes
git tag v1.2.4  # Security fix version for 1.2.3

Patterns to avoid:

# ❌ Non-compliant with semantic versioning
git tag release-2024-03-15
git tag latest
git tag stable

# ❌ Irregular naming
git tag v1.2.3-SNAPSHOT
git tag 1.2.3-final

Release Strategy

Staged release pattern:

1. alpha - Testing by internal developers
2. beta - Testing by limited users
3. rc (Release Candidate) - Testing in production-like conditions
4. Official version - Production environment deployment

Example:

v2.1.0-alpha    → Development environment
v2.1.0-beta.1   → Staging environment
v2.1.0-rc.1     → Staging environment (production-equivalent configuration)
v2.1.0          → Production environment

Troubleshooting

Common Issues and Solutions

Version not detected:

# Debug: Check available tags
curl -s https://api.github.com/repos/owner/repo/releases \
  | jq -r '.[].tag_name'

# Check detection process in logs
dewy server --log-format json -l debug --registry ghr://owner/repo

Unexpected version selected:

# Check pre-release settings
dewy server --registry "ghr://owner/repo?pre-release=false"  # Stable only
dewy server --registry "ghr://owner/repo?pre-release=true"   # Include pre-release

Access permission issues:

# Check GitHub Token
echo $GITHUB_TOKEN | cut -c1-10  # Display only first 10 characters
gh auth status  # Check authentication status with GitHub CLI

Related Topics

• Registry - Version detection source configuration and registry details
• Cache - Version information and artifact storage management
• Architecture - Dewy's overall configuration and deployment process
• FAQ - Frequently asked questions about versioning