ci: Use semantic release development workflow#360
Merged
Conversation
scq
approved these changes
Oct 9, 2025
scq
approved these changes
Oct 9, 2025
|
Continuous delivery for the win! Great move imo. |
jakub-krauz-totara
approved these changes
Oct 9, 2025
Contributor
Author
|
Have got security approval from Nate on this |
Contributor
Author
|
FYI: Made some small grammar changes to CONTRIBUTING.md |
|
🎉 This PR is included in version 1.18.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Having to manually make releases seems somewhat arbitrary given that a lot of the changes are often unrelated, and desired by different teams. Wanting to remove the amount of effort to make and release changes, and make it so it's more decentralised so individual teams can make changes without having to involve others/wait for the next manual release (of which we don't really have a schedule for)
I’m proposing that we switch from the current release model (of merging into develop, then merging into master and manually creating a release) to a model where:
This then creates a release that looks like this (in my personal fork) that uses the conventional commit message to determine whether to increment the minor or patch version, and uses it to autogenerate release notes.