Hi @jacksbox, @williamluke4 & @danth

I've been using the Node semantic-release for a while & in the process of converting to this to eliminate the need for Node installation on some Jenkins agents, and was looking to see if this was a feature today/came across this issue. I use pyproject.toml for configuration so 🙏 please guide me if anything doesn't fit for setup.cfg, my level of understanding is "read the docs" for the latter.
If it was free-reign I think I'd look to implement the following:

Proposals

1. Create a new sub-table configuration option, something like

[tool.semantic_release.branches]
"branch regex" = <per-branch config dict>
# e.g.
main = true # always release
"^dev-?.*" = {prerelease = true, prerelease_tag = "alpha"}

I believe it's possible to create the same kind of structure in setup.cfg:

[tool:semantic_release.branches]
"^dev-*$"=
    =prerelease = true
    =prerelease_tag = "alpha"

but admittedly haven't really tested yet.

This kind've follows the options available in the Node semantic-release configuration, and would allow a per-branch pattern configuration to hook into.

I had some ideas around defining keys such as force_major, force_minor and force_patch as boolean flags, which would help with multibranch CI pipelines when a user wants to associate a specific meaning with their branch naming conventions.
I also wonder if there's value in capturing groups from the branch regex for use in the config too - food for thought 🤔 ?

I think this will hook into the recent pre-release functionality pretty well as the recent inclusion of pre-release functionality in your PR, since (if I understood correctly) that relies on setting a flag True/False for whether we are or aren't doing a pre-release - it should be doable to grab that from the per-branch config structure above, provided we can match on branch name.

A question I still have is what the default should look like - I suggest a default which has the same effect as

[tool.semantic_release.branches]
master = true

but the specifics will depend on what options are allowed in that per-branch configuration. It could go as granular as allowing most other configuration settings (e.g. upload_to_repository, upload_to_release etc) to be done on a per-branch-pattern basis, or kept pretty tight in the first instance. Ultimately though I do think that being able to set most keys under Distribution and maybe Commits (at least commit message?) would be useful functionality.

2. Deprecate the branch configuration key

In favour of using the sub-table as outlined above.

3. Change the default behaviour around branches

Instead of checking the branch out from the configuration's branch key, semantic-release should check the current branch that the user is on in their repository, and if it doesn't match any configuration then should probably just print a message and exit gracefully.

Implementation

I think 1 and 2 are do-able without introducing any breaking changes, however the change to the default behaviour 3 will be what really makes the multibranching config come alive. All the while semantic-release is limited to checking out a target branch and then releasing, I guess the table for multibranching would have somewhat limited value.

What do you think of this? If no-one is looking at it yet I should have some space in the next couple of weeks to start drafting a PR, but better to get your thoughts first 🙂.

EDIT: removed the suggestion for "branch regex" = false, would be unneeded compared to simply not configuring semantic-release to run a release on that branch pattern.

@relekang hi, came to check on this and realised I didn't include you in the set of tags- sorry about that! I'd love to get your thoughts on the above, if that's a direction python-semantic-release could go in

This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

Hi I'm also interested in this features, I was thinking on just add branch to the semantic-release command as a paremeter, but not sure if the inner-workings allow this
something like:
semantic-release --prerelease branch=develop
will be used if for example the merge is to the "develop" branch
if the merge is to the "master" branch it could be
semantic-release branch=master

This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.

Completed in v8 release.