Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should both dune-release and opam-publish be in the Platform? #22

Open
pitag-ha opened this issue May 10, 2022 · 1 comment
Open

Should both dune-release and opam-publish be in the Platform? #22

pitag-ha opened this issue May 10, 2022 · 1 comment

Comments

@pitag-ha
Copy link
Member

pitag-ha commented May 10, 2022

As mentioned very briefly at the end of https://github.com/tarides/ocaml-platform/issues/19, we need to discuss what to do about the situation that both dune-release and opam-publish are in the Platform. The current suggestion in our state of the Platform docs is simply to demote opam-publish to the Sustained category and to promote dune-release to Active. Of course, that would be the simplest solution. Do you think the community in general would be behind that decision?

Difference between the two tools

As far as I can tell, the differences between the two tools are:

  • dune-release is more opinionated that opam-publish
    • opam-publish is build system agnostic, whereas the usual/recommended dune-release workflow relies on dune being used (it's possible to use dune-release to do the same as opam publish does, but that's quite a bit more tedious and it's not the "dune-release philosophy" to do so)
    • dune-release by default requires a changelos fulfilling a certain standard
    • dune-release by default requires using github
    • dune-release runs dune subst which can be considered invasive/unreliable by some
  • dune-release has a wider scope than opam-publish
    • it can do the whole release for you
    • in particular, it can create a github release (as opposed to a github tag), including a reliable release tarball and release notes
    • before the release is realized, there's a lint/check mechanism. opam-publish only has a minimal linting mechanism linting the generated opam file
    • before creating the tarball, it substitutes watermarks etc (dune subst)
    • a couple of details like adding a x-commit-hash field to the opam file, which is good for vendoring
  • opam-publish can be more convenient wrt certain workflows and problems
    • with the opam-publish workflow it's way more straight-forward to force push a tag and then publish the modified release on opam. (in the future, hopefully that problem will be solved in dune-release by its WIP draft release feature)
    • opam-publish currently needs less configuration (is that correct?)

Discussion

I don't have an opinion about what to do with these two tools myself yet. So far, I've just been working out the differences between the two tools. I'm discussing with the maintainers what they think and if there might be implementation parts/ideas of opam-publish that could serve dune-release as well and in that sense it would make more sense to "merge" the two tools instead of moving one of the tools on the path to get deprecated and keeping only one without collaboration. If anyone here has an opinion or more context on this, please let me know!

@panglesd
Copy link
Contributor

Note: in the first release, only dune-release is included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants