To make the usage of dune-release more approachable we need to make it as convenient to use as possible and to force users through the least amounts of hoops to jump through.
As such, the usage of dune-release currently requires dune-release tag (or manual tagging) and dune-release [bistro] to do the full flow. This requires more work from the user to learn how dune-release works.
Hence it would be better to include tag into the dune-release workflow. The current tag would not go away, if people prefer to be explicit nor would this obsolete manual tagging via git, it should mostly be smart about releasing.
As such this new optional needs to tag if a tag is required (e.g. changelog contains a new, not-yet tagged version) but also detect if a tag exists, either via manual creation or dune-release tag. In case a tag is required it should allow the user to create it, if there is a sufficient tag it should report it to the user and continue with the rest of the release flow.
To make the usage of
dune-releasemore approachable we need to make it as convenient to use as possible and to force users through the least amounts of hoops to jump through.As such, the usage of
dune-releasecurrently requiresdune-release tag(or manual tagging) anddune-release [bistro]to do the full flow. This requires more work from the user to learn howdune-releaseworks.Hence it would be better to include
taginto thedune-releaseworkflow. The currenttagwould not go away, if people prefer to be explicit nor would this obsolete manual tagging viagit, it should mostly be smart about releasing.As such this new optional needs to
tagif a tag is required (e.g. changelog contains a new, not-yet tagged version) but also detect if a tag exists, either via manual creation ordune-release tag. In case a tag is required it should allow the user to create it, if there is a sufficient tag it should report it to the user and continue with the rest of the release flow.