Pierre Vanduynslager

> I don't see the risk any longer of accidentally deleting one of the semantic-release/* any longer. See https://github.com/semantic-release/semantic-release/pull/1372/checks?check_run_id=325716677#step:19:88 Now the permission are limited which is great. But still it...

> I suggest I move out the end-to-end tests from semantic-release and move them instead into a repository in @semantic-release-test. I can use dispatch events to trigger builds and use...

An interesting thing to do in end-to-end test would be to test different CIs. See https://github.com/semantic-release/semantic-release/pull/1376 Each CI has a different way to clone the repo and that can have...

You can also use the [@semantic-release/exec](https://github.com/semantic-release/exec) to run a script at any step you'd like that can be passed the new version number. Something like that: ```json { "release": {...

> The problem with all these solutions is that I need to have two configurations : One that outputs the version or sets it somewhere, and one for the actual...

Thanks for the clarification. semantic-release is build around the following ideas: - A release consist in running test, defining the version then releasing - A given release happens only once...

In most cases where such feature was requested there was a better solution to implement the desired workflow, so it hasn't been implemented so far. It seems the workflow explained...

@andresmijares could you explain your workflow and why such feature would be useful to you?

Can you clarify what "I havent had any luck with it" means? Is it not working? What's the problem?

btw, as indicated in [semantic-release/exec#usage](https://github.com/semantic-release/exec#usage) the proper syntax is `${nextRelease.version}` not `${version}`. So your config should be: ```js "release": { "prepare": [{ "path": "@semantic-release/exec", "cmd": "./build.sh --release -v ${nextRelease.version}" }]...