Replies: 1 comment 1 reply
-
|
please clarify what you mean by "draft" in this context. semantic-release follows typical git conventions. if you mean having the ability to include multiple changes before triggering a release, that is a matter of deciding which changes to add to your branch before merging. if you mean having a sort of preview before merging, we dont currently have that functionality (we may someday, but not today). the best we provide as a preview is the understanding that we always operate on commits, so reviewing the commit messages of the changes in the branch you intend to merge makes it quite clear what would be expected once you merge the branch to your release branch |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking of the "preview" option that you described. Is there an issue that I can follow for that enhancement in the future? |
Beta Was this translation helpful? Give feedback.
-
I'm investigating semantic-release for automating the release and deploy for a variety of our projects ranging from web applications, to python/npm packages, to GitHub actions, etc. This project seems awesome and the plugin ecosystem looks very promising. However, I'm struggling to figure out if semantic-release will fit into our existing release procedure. We currently use release-please to create draft releases pull requests anytime we commit to a release branch. These draft releases allow us to defer a release until we are ready. Then when we are ready to do a release, we merge the release pull request and the release is deployed. We like this as it allows us to keep our change log cleaner and we have more control over the timing of a release so that we can coordinate with other systems. Another example of this type of workflow is the release-drafter project.
Is this possible via semantic-release? Perhaps it would require the use of a custom plugin? I've messed around a little but am having troubles with separating the release process into two parts. The first part would be analyze commits, generate the next version, bump version files, write the changelog, commit, and open a release PR (or a draft release would work). Then the second part would be generating/finalizing the GitHub release and deploying the release.
I'd love any ideas or suggestions. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions