Release governance and versioning strategy

[michaelstingl]

Following up on @butonic's comment in #43 about version implications and the need for clear release practices.

Problem

We need a simple, documented process for:

• Who can create releases/tags
• When releases should be made
• How version numbers should be incremented

Proposal

Add a minimal "Release Process" section to CONTRIBUTING.md that covers:

1. Authority: Only maintainers can create releases
2. Versioning (during 0.x.x phase):
   • 0.x.0 - Breaking changes
   • 0.x.y - New features (backwards compatible)
   • 0.x.y-z - Bug fixes only
3. Process: Simple checklist for creating releases

This would complement the version stability disclaimer added in #43 and help manage expectations around breaking changes.

Keeping it simple and community-friendly while providing necessary structure.

cc @butonic @wrenix @ferenc-hechler @suse-coder - would appreciate your input on this governance proposal!

[michaelstingl]

I've implemented a solution for this in PR #49, which now includes:

1. Release process documentation in CONTRIBUTING.md
2. Automated version consistency checks in the publish workflow

The version checks will:

• Validate that all chart versions use proper semver format
• Warn when a git tag doesn't match the chart versions
• Show exactly which versions will be overwritten during tag releases

You can see the specific commit here: ferenc-hechler@eec4394

This should help prevent version inconsistencies and provide clear guidance for the release process.

[michaelstingl]

Chart-specific versioning proposal

I've been thinking about the versioning strategy, especially now that we're about to have 3 different charts (opencloud, opencloud-dev, and soon opencloud-microservices from PR #52).

Current situation:

• opencloud: version 0.2.3
• opencloud-dev: version 0.1.0
• opencloud-microservices: version 0.8.0 (incoming)

The current workflow overwrites all chart versions when a tag is pushed, which could be problematic.

Proposal: Chart-specific tags and releases

Instead of using generic tags like v0.3.0 that update all charts, we could use chart-specific tags:

Tag format:

• opencloud-v0.2.4
• opencloud-dev-v0.1.1
• opencloud-microservices-v0.8.1

Benefits:

1. Each chart maintains its own version independently
2. Only changed charts need new releases
3. Clear mapping: tag → specific chart → specific version
4. Different charts can have different release cycles
5. No unnecessary version bumps for unchanged charts

Workflow changes needed:

• Modify the GitHub Actions workflow to detect which chart to build based on the tag prefix
• Only package and push the specific chart that matches the tag
• Keep the version in Chart.yaml as the source of truth

Example workflow snippet:

on:
  push:
    tags:
      - 'opencloud-v*'
      - 'opencloud-dev-v*'
      - 'opencloud-microservices-v*'

This would allow us to release opencloud-v0.3.0 without touching the other charts.

What do you think about this approach? It would give us more flexibility while keeping things organized.

cc @butonic @wrenix @ferenc-hechler @suse-coder

[suse-coder]

Sounds good

[wrenix]

Like you descripe, Helm-charts should use Semantic-versioning. Current we are at beta so breaking changes are at minor level. Later somewhere it becomes major level.

The helm-chart Version should be independent of AppVersion, like you describe. so i am fine with it.