Proposal for a Maintainable Release Workflow Adapting to Automatic Release

[msclock]

The proposal aims to discuss how to establish a maintainable release workflow that adapts to automatic release. Traditional release processes may require a lot of manual intervention and manual operations, which can lead to errors and delays. The concept of automatic release is to use automation tools and processes to simplify and speed up the release process, thereby improving efficiency and reducing errors.

In this discussion, we can explore the following aspects:

1. Advantages of automatic release: We can discuss the advantages of automatic release compared to traditional release methods. For example, automatic release can reduce manual intervention, improve release speed, reduce error rates, and so on.

2. Considerations for maintainability: We can discuss how to ensure the maintainability of automatic release. This may involve discussions on version control, automated testing, error monitoring, and rollback mechanisms.

3. Workflow design: We can discuss how to design a workflow that adapts to automatic release. This may include defining release stages, selecting automation tools, ci, and cd.

4. Continuous improvement: We can discuss how to continuously improve the automatic release workflow. This may include regularly evaluating and optimizing the workflow, as well as making adjustments based on feedback and experience.

Through these discussions, we can gain a deeper understanding of how to establish a maintainable release workflow that adapts to automatic release and achieve higher efficiency and quality.

[msclock]

Here we haved introduced a non-language-specific automatic semantic release management based on semantic-release.

Normally, there are three release workflows:

• Distribution channels
• Maintenance release
• Pre-release

Here are some examples about the configuration using semantic-release:

• https://github.com/serious-scaffold/cpp-scaffold/blob/master/.releaserc.js
• https://gitlab.com/msclock/gitlab-ci-templates/-/blob/master/.releaserc.js

[huxuan]

I really appreciate this!

There are only three (two minor and one primary) concerns from my side.

1. Support both GitHub and GitLab.

2. Support both public and private repos.

3. Personally, I treat v1.0.0 as a very serious release (ruff and fastapi could be an example for my preference), there may have some conflicts with semantic release logic. Any workaround for this? Or maybe I should switch to pre-release pattern instead?

BTW, I use git-changelog for changelog generation, better to align the commit convention with it: https://pawamoy.github.io/git-changelog/usage/#angularkarma-convention

[msclock]

@huxuan

Account for 1 and 2, it idefinitely supports on both GitHub and GitLab, and I have maintained some templates and relevant docs for automatic release from the repo.

Account for 3, my experience is to manually create the version number 0.0.0 starting from major version 0, because it detects the existing tags in history and increments them to determine the future version number. Also, pre-release is recommended officially. But I'm fine with both.

[huxuan]

That is cool! I should drop the deprecated idea of v0.0.1 and adhere to pre-release instead. I will further look into it.