Replacing dune-release delegates

@NathanReb wrote:

The plan is described in detail in this issue but I’ll try to summarize it here.

Natively, dune-release only knows how to publish documentation and distribution tarballs to github. It offers a delegate API so that you can implement your own publication command for documentation, tarballs or any extra item.

When publishing dune-release will parse the various URIs in your package’s opam file (home, doc or dev-repo). If the domain name for those URIs is not github.com, it will try to publish the corresponding item by invoking the delegate for that domain name (e.g. for readthedocs.org it will call the command readthedocs-dune-release-delegate) providing it a fixed set of command line arguments comprised of the path to the distribution tarball or the documentation directory and the publication message (the last section of the changelog by default).

This API is fragile and add quite a bit of logic in dune-release which is otherwise quite simple and straightforward.

What we suggest is to invert the relationship between external scripts and dune-release by providing a new command that can be invoked to obtain the information dune-release was passing on to the delegate commands.
The command would take a variable name as a command line argument and print its value on the standard output. If a script requires the path to the tarball it could use $(dune-release info tarball-path) to get it.

The idea is that now, external scripts would invoke dune-release and not the other way around.
This has the advantage to allow for extending this API without breaking existing scripts.

If you currently are using delegates or were planning on using them we’d like to know how, why and most importantly if this proposition prevents you from releasing with dune-release.

The current plan for delegates is:

1. To provide that new dune-release info command in the next 1.4.0 minor release
2. To depecrate any other delegate related features in the subsequent minor release
3. To remove the delegate API in the 2.0.0 release

Alternatively, we’d be interested in hearing from people that do not use Github for their release process and learn what they use instead. We’d be happy to add support for different release processes given there is enough demand for it. For example, adding support for Gitlab or plain ftp/ssh/rsync seems reasonable.

Posts: 1

Participants: 1

Read full topic