I’m migrating a package from a Make-based build to a dune-based build and made a bad release in the process. I missed a test dependency. I’m trying to remedy this situation, but I’m too much of a novice in the opam world.
The mistake was a simple one. I forgot to add (depends (ounit2 :with-test)) to the package in my dune-project file. I’ve fixed this and pushed the change to master in my repository.
Now I want to fix the release. I used dune-release to make the release. It created tags, made a tgz release on GitHub, and opened a pull request. All of these need to be fixed. Is there a way to make dune-release fix this?
Closing the PR is all you really need to do to prevent the bad release from going into opam. Of course, maybe one day we get a package registry that’s not controlled with PRs to a GH repo, but for now this is it
Hi, just a side note: you didn’t have to re-release to fix it. I had already fixed it the opam file in 819185 directly in your PR and these fields are pretty much totally ignored in a release archive (the whole dune-project file even, with very few exceptions), they’re only there to generate the opam file sent to opam-repository.
It’s totally fine to re-release of course but just so you know.
Thanks @kit-ty-kate for fixing my PR. Unfortunately, the result was an inconsistency between my release and the opam release. Clearly the error was in my dune-project file and the opam file was merely derived from that file. I could have fixed my package files, but I would also need to patch the checksum.
Unfortunately when I tried to do this, and pull your changes, the merge failed for some reason and I ended up with a git repo that said that is up to date, had incorporated your changes and my changes and yet did not have your changes. Hence the desire for a more automated process.
To come back to your question if dune-release provides a way to delete or modify all those artefacts it creates during the release process: it doesn’t at the moment. It also seems to me that, if there were a way in dune-release to delete or modify the github release, it might wrongly encourage people to do so. In most cases, the best way to “fix” a release -even if it didn’t make it to an opam package- is to make a new patch release. But I agree that what you describe of deleting five things by hand sounds pretty tegious.
There’s an issue -and PR for it- that addresses the problem of not being able to get feedback from the opam-repository CI before releasing to github: the plan is for dune-release to support a draft release workflow.
So you could make a “dune-release draft release”, i.e. a github draft release with a corresponding draft PR to the opam-repository, and you could “dune-release undraft” it if it passes the opam-repository CI, possibly after fixing a detail in the opam file submitted. If there isn’t a consistent way to fix it by only touching the opam file submitted, it would be no problem to delete that draft release and it would make perfect sense to have dune-release take care of it by also deleting everything created on the way. So I think what you’re suggesting dune-release should be able to do is a good idea for the future.
