Handle micro-releases

[nicolasbisurgi]

Proposal: Automated Micro-Release Management

Current State

TM1Py currently uses a manual release process with versions like 2.0, 2.1, 2.2, etc.

Problems with the current approach:

• Releases are infrequent and manual
• PyPI publishing is manual
• Users have to wait for releases to get bug fixes and improvements

Proposed Change: Automated Micro-Releases

We propose switching to automated micro-releases with semantic versioning (e.g., 2.1.1, 2.1.2, 2.1.3, etc.).

How It Would Work

Default Behavior - Automatic Patch Releases:

• Every merge to master automatically creates a new micro-release
• Version increments automatically: 2.1.5 → 2.1.6
• Automatically published to PyPI
• GitHub Release created with changelog
• Documentation updated

Example:

Current version: 2.1.5
Developer merges bug fix PR → Auto-released as 2.1.6
Developer merges another PR → Auto-released as 2.1.7

For Minor Version Bumps:
When we want 2.1.5 → 2.2.0 (new features), we can:

• Add a release:minor label to the PR, OR
• Use conventional commit message: feat: add new feature

For Major Version Bumps:
When we want 2.1.5 → 3.0.0 (breaking changes), we can:

• Add a release:major label to the PR, OR
• Include BREAKING CHANGE: in the commit message

Skip Releases:
For documentation-only changes or other non-release commits:

• Add skip-release label to the PR
• No version bump, no PyPI publish

Benefits

For Users

• Faster access to fixes - Bug fixes available on PyPI within minutes of merge
• Predictable releases - Know that every improvement is immediately available
• Better pip install experience - Always get the latest stable version
• Clear version history - Easy to track what changed between versions

For Maintainers

• Less manual work - No more manual version bumping, tagging, and publishing
• Consistent process - Automated workflow eliminates human error
• Version sync - Single source of truth for version numbers
• Better changelog - Auto-generated from commits

We can always revert since we already support semantic release.

Please let me know your thoughts!

[onefloid]

I really like this proposal. If we pursue this approach, we should exclude commits like ci, refactor, test, and docs from triggering releases, and any commit containing [skip release] should skip the release as well.
We should also keep the ability to accumulate a few commits before releasing, without having to work with a separate branch. And we would also need a bot that validates commit message syntax and prevents merging when messages don’t follow the expected format.

But my main concern:
I don’t think the community is ready for fully semantic commits yet, and we should keep control over when releases are triggered.
So I would prefer using tags that explicitly trigger a release, rather than publishing automatically on every merge.

[nicolasbisurgi]

Hi @onefloid - thanks for the feedback!
We can still control the versioning by labeling the PR itself (regardless of what the branch name is or the commit message says); they would override any branch naming convention and commit message. The default behavior would be to increment the version by one (2.1.1 to 2.1.2), but by using PR labels we can:

• Add a release:minor label to the PR before merging: 2.1.2 → 2.2.0 or
• Add a release:major label to the PR before merging: 2.1.5 → 3.0.0 or
• Add a skip-release label to the PR for documentation-only changes or other non-release commits.

This would mean:

• No bot needed to validate commit syntax
• No blocking PRs due to message format
• Maintainers control release type via labels (added before merge)
• Conventional commits are just an optional convenience

Would this address your concerns? Or did I miss something?

Cheers!

Nico

[onefloid]

Hi @nicolasbisurgi,
Controlling releases through PR labels is a good approach. I like that it keeps things explicit and avoids blocking contributors with strict commit message rules.

If we follow this model, I think the default behavior should be “no release” unless a label is set. This avoids accidental micro-releases and gives maintainers full control over when something gets published. It also helps us batch multiple commits if needed without relying on extra branches.

Regarding the test suite:
Ideally, we would run the full suite on every merge, because that makes it very clear which change breaks something. But as far as I know, we cannot run tests in parallel on CI right now, since the tests share the same TM1 instance and aren’t fully isolated yet. That means we would need some kind of queue to serialize runs until the test isolation problem is solved.

Cheers!
onefloid

[nicolasbisurgi]

Switching the default behavior from patching to skip-release is fine by me, specially now that we are working on lots of non-tm1py code things.
Regarding the test suite and its "lengthiness" :)
I would propose do PR merges during the day but keep the releases at midnight:

1. During the day: Merge PRs to master after quick smoke tests (a ~5-10 min we could develop to catch obvious things)
2. At midnight:
   2.1 GitHub Action triggers full 2-3 hour test suite
   2.2 If tests pass → Create ONE release with all the day's changes
   2.3 If tests fail → Don't release, create issue for maintainers
3. Labels still control version bump:
   3.1 If any merged PR had release:minor → bump minor
   3.2 Otherwise → bump patch

An example would be:
10am: Merge PR #123 (bug fix) - quick tests pass
2pm: Merge PR #124 (feature, labeled release:minor) - quick tests pass
5pm: Merge PR #125 (bug fix) - quick tests pass
12am: Full test suite runs (2-3 hours)
3am: Tests pass → Release 2.2.0 (because of the minor label)
Changelog: Includes all 3 PRs

Thoughts?

[onefloid]

Sounds good to me, sold as suggested.
Plus one addition: we should tag the commit, when the release is successfully.

[MariusWirtz]

Controlling releases through PR labels is a good approach. I like that it keeps things explicit and avoids blocking contributors with strict commit message rules.

Totally agree with the labels.
We might need to review permissions about who can place labels on PRs.

3.2 Otherwise → bump patch

Do you mean patch release as in micro release 2.1.1 ?

Regarding the auto increments we need to make sure that 2.9.3 does the minor increment to 2.10 instead of 3.0, if that isn't the default behaviour. The major releases we obviously want to reserve for major and breaking changes...