Configure release branch prefix
Closed this issue · 5 comments
Feature Request
| Q | A |
|---|---|
| New Feature | yes |
| RFC | no? |
| BC Break | no |
Summary
I would love to use the tool for managing the releases for my companies packages. Back in the days, we decided to add a prefix to our release branches (e.g. /releases/). Since I would love to keep that, I am wondering if you are open to add a configuration option that would allow this behavior.
This would basically mean to introduce a new env var that defines the release branch prefix and extend the \Laminas\AutomaticReleases\Git\Value::isReleaseBranch() to deal with the branch prefix. If the env var is not defined or empty, the current behavior is kept.
Happy to work on this if it makes sense for you.
Since I would love to keep that, I am wondering if you are open to add a configuration option that would allow this behavior.
IMO not through a configuration.
What can be done is adapting the VO to also accept the release/ prefix, but it would still create new branches as 1.2.x rather than using your prefix.
Overall, adding configuration makes the tool much (much!) more complex, and should be avoided unless absolutely necessary (doesn't seem to be the case)
Thanks for your feedback. I do understand your point of view to not introduce more complexity than needed. That's why I asked before providing a PR :)
I don't like the approach to accept a prefix but not use it to create new branches. Ideally, both cases should deal with the prefix handling. If you think the feature request adds too much complexity to maintain in the long run, feel free to close the issue.
@shochdoerfer if we can make it work without configuration, that's OK.
With configuration is a blocker though, as the tool should really be near-zero-config (and already requires way too much).
In addition to that, the complexity of the e2e testing of this tool, due to the entire workflow being quite complex itself, are really not worth the effort if it's just a question of naming (which can be adjusted/aliased on your end).
Specifically, what you can do in your .workflow/my-release-workflow.yml is:
- adding a
git checkout -b 1.2.x release/1.2.x - adding a
git checkout -b release/1.3.x 1.3.x
The above with some bash-fu, but basically allows the tool to operate with the current assumptions, and what you do on your end is a rename before and after the tool has run.
Thanks, but that is too much complexity in the workflow then. I'd rather need to decide to use the tool and live with the release branch name mix or don't use the tool at all. Both would be fine, I guess ;)
Alrighty - closing here for now then. Consider the added steps before/after as a possible approach though, as it is indeed a relatively simple solution to some otherwise quite complex scenarios.