tarides
Integrate `tag` command into main `dune-release` invocation
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.
Thanks @Leonidas-from-XIV, also for already giving quite some detail on this issue!
I'm about to start working on this. I've just had a look and the current flow of tag is already pretty close to what we want: a tag is created only if a tag with that name doesn't exist already; and, if there are several tags pointing to HEAD, then the last created tag is used for the rest of the release. So what's missing in that regard is to prompt the user if they really want to add a second (or nth) tag on HEAD if there is already one with a different name.
Furthermore, there's one more thing that I'd adapt to the new workflow (apart from adding general context to the logging messages), and that would also be breaking even for dune-release tag: Currently, dune-release tag takes the release version as an optional positional argument (as in dune-release tag 2.5.1). For the general command, it would be better to make it an optional named argument (as in dune-release --version=2.5.1). So for consistency between the general command and the tag command, it would also be better to make it an optional named argument also in tag (as in dune-release tag --verion=2.5.1). What do you think, @Leonidas-from-XIV and @NathanReb?
@pitag-ha Thanks for looking into it. Good to know that most of the logic is already in place.
Personally I completely agree with your assessment, dune-release tag --version=2.5.1 is more consistent and doesn't make it worse. Since this is a 2.0 change I don't mind it at all.
From an user point of view: I am currently using dune-release on projects that don't have a changelog and already have to dune-release tag 2.5.1+dune -m "MESSAGE", thus I need -m anyway, therefore --version doesn't make this particularly worse and is even a bit more descriptive.