DEV Community

Query Filter
Query Filter

Posted on

docker64

This draft is designed to be sent to your team (e.g., via email, Jira, or Confluence) to clearly communicate the technical changes while forcing a decision on the critical architectural question regarding version sources.

Release Notes: RPM Versioning Migration

Branch: leonid-comet-lse-migration
Status: Ready for Review / Technical Decision Required

1. Overview

The COMET project migration is complete. We have shifted to a standardized RPM versioning scheme. This migration moves us away from manual deployment artifacts toward a fully versioned, package-managed infrastructure.

The new format follows: Artifact-AppVersion-AppRelease-Architecture.rpm

2. Decision Required: Source of Truth

We currently have AppVersion and AppRelease hard-coded within build.gradle. To improve CI/CD agility, we need to decide on the path forward for variable injection.

Approach Pros Cons
Current (Gradle Hard-code) Simplest to implement; tracks version with code. Requires code commit for every version bump.
Dynamic (Tekton/Env Injection) Decouples build from versioning; cleaner pipeline. Requires strict Tekton configuration management.

Discussion Point: I am proposing we move these variables to be controlled by our orchestration layer (Tekton/Environment variables) to automate releases. Does the team have a preference or specific security constraints regarding external variable injection?

3. RPM Behavior & Deployment Logic

To ensure everyone is aligned on the new deployment behavior, please note the following operational logic:

Versioning Logic

  • Version Construction: ArtifactId + AppVersion + AppRelease determine the version.
  • Artifact Isolation: Changing ArtifactId (e.g., CPLS to CPLSdev) treats the new build as a distinct entity. Previous directories/binaries are not touched.

Critical Behavior: The Cleanup

  • Destructive Updates: When AppVersion or AppRelease is changed, the system is designed to remove the previous release directories to ensure a clean state.
    • Note: Ensure all data persistence layers are decoupled from these application directories.
  • Downgrade Support: Unlike standard YUM behavior, our system is explicitly configured to support downgrades. If a rollback is required, we can enforce it by modifying the AppVersion and AppRelease and re-running the build cycle.

4. Next Steps for the Team

  1. Code Review: Please review the logic in branch leonid-comet-lse-migration.
  2. Decide: Confirm the source for AppVersion and AppRelease (Gradle vs. Pipeline/Env).

Top comments (0)