In the context of your COMET project, both Version and Release act as triggers for your "wipe-and-replace" installation logic. While they both force a reinstall, maintaining them as separate fields is an industry standard that serves two different purposes in your CI/CD pipeline.
The Conceptual Difference
Think of your RPM as a product. The Version is the product itself, and the Release is the specific iteration of the packaging for that product.
| Component | Represents | Change Trigger (The "Why") |
|---|---|---|
| Version | The Code | You changed the Java source code, added a feature, or fixed a bug. |
| Release | The Build/Infra | You kept the code the same, but fixed a broken config file, changed a dependency, or rebuilt the artifact after a pipeline failure. |
Why you need both in a "Wipe and Replace" Model
Even though both trigger a reinstall, having two separate variables prevents "version bloat" and provides essential auditability.
1. Preventing "Version Bloat"
If you only had a single number (e.g., just "Version 1.1, 1.2, 1.3"), you would be forced to bump the application version every time you made a minor infrastructure change.
-
The Problem: If you fix a typo in your startup script but keep the application code identical, bumping the version to
1.2.1is misleading. It suggests the software logic changed when it didn't. -
The Solution: You keep the version at
1.2.0and bump the release to2. You now know exactly why the package was reinstalled without misrepresenting the state of the software.
2. Granular Traceability
In a CI/CD environment like Tekton, you likely want to differentiate between "Code Releases" and "Build Re-runs."
-
Auditing: When you look at your artifact repository (Artifactory), you can see:
-
CPLS-1.0.0-1.rpm(Initial build) -
CPLS-1.0.0-2.rpm(Packaging fix: e.g., fixing a missing directory permission) -
CPLS-1.0.1-1.rpm(Code update: new feature)
-
-
Troubleshooting: If
1.0.0-2introduces a bug that1.0.0-1didn't have, you immediately know the issue is in your packaging logic, not the application code.
Summary of Impact on your Pipeline
In your "destructive" installation model, the RPM manager and your automation do not care why the value changed—they only care that the value is different.
- If either value changes: The system detects a unique RPM signature, triggers the "wipe" of the old directory, and installs the new one.
- The dual-value system: It gives you the ability to differentiate between "I am deploying new code" (Version) and "I am deploying a fixed package" (Release), while maintaining the strict cleanliness your deployment model requires.
Top comments (0)