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!
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
andopam-publish
are in the Platform. The current suggestion in our state of the Platform docs is simply to demoteopam-publish
to the Sustained category and to promotedune-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 thatopam-publish
opam-publish
is build system agnostic, whereas the usual/recommendeddune-release
workflow relies ondune
being used (it's possible to usedune-release
to do the same asopam 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 standarddune-release
by default requires using githubdune-release
runsdune subst
which can be considered invasive/unreliable by somedune-release
has a wider scope thanopam-publish
opam-publish
only has a minimal linting mechanism linting the generated opam filedune subst
)x-commit-hash
field to the opam file, which is good for vendoringopam-publish
can be more convenient wrt certain workflows and problemsopam-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 indune-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 servedune-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!