Nathan Rebours

Maybe a better suited name would do the trick, something like `dune-release auto` or `dune-release all`. Adding documentation and stating that it's the default command seems good enough but I...

I think it's fine to remove it in 2.0 without warning. Not best practice but I doubt anybody has a script that runs `dune-release bistro` so it's unlikely to break...

That all seems sensible to me, except probably for 2 which I'd much rather replace entirely with 3. We already implemented 4 a while ago but it hasn't been released...

I think it's historically been that way and some people like that it is that strict. I understand this can be annoying so you should know that in the meantime...

Thanks for reporting this! I'll have a look, should be fairly easy to fix!

I can't reproduce this with the latest `dune-release` on a dummy package with a custom `homepage` field and as I don't have right access to `cppo` ,`dune-release publish distrib` fails...

I figured it out, I'll try and fix it but the whole parsing code is scattered across various different places and I'd like to find a proper solution to this...

Same here as with #406, we should still check the version field but simply error out when it's too old instead of running the conversion to 2.x.

Thanks for your contribution! Getting rid of external binary dependencies is indeed something that we would like to do in dune-release and have discussed in recent dev meetings. Some parts...

I think it's worth noting that even if we stop parsing dune-project for the tarball name it might still be good to use sexp for our config. Since we interact...