Skip to content

πŸ“ Documentation: Batching multiple commits for a single release or triggering a new release after the factΒ #2055

@ChristianIvicevic

Description

@ChristianIvicevic

Documentation Report Checklist

Overview

I have scaffolded a new package using your template and got it working for the most part but noticed a few unclear steps in terms of the intended workflow and would like to know how to handle these as I haven't seen sufficient documentation on it.

  1. Creating the repository also sets up GitHub in an opinionated way, specifically disabling rebases and forcing everything to be squashed. As such anything that ends up in the main branch will always be a single commit, be it directly to main or via a PR. The release workflow therefore cannot pick up multiple changes at the same time, say two features. This is particularly relevant when I'm preparing a minor or even a major version release and wouldn't want all the separate changes be summarized under a single umbrealla feat entry in the changelog and instead would like my users to actually see in detail what has changed. What's the recommended process to batch these changes for a single release?
  2. In a similar fashion certain commits such as dependency updates don't trigger a release since they are prefixed with chore, especially when it's from renovate. What about the case where a critical vulnerability gets updated? This doesn't trigger a release and it seems I'd have to push an empty commit with fix to trigger a release which really doesn't feel right. How am I supposed with the default setup to trigger a release after performing some more relevant dependency updates?

Additional Info

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions