dev meeting 20220310

Present at the meeting:

• Nathan Rebours (@NathanReb)
• Marek Kubica (@Leonidas-from-XIV)

Meeting notes

Since the last meeting we released dune-release 1.6.1 with the support for Cmdliner 1.1.0 which we assume to be the final 1.x release.

After that release happened the delegate removal PR was merged which due to being a breaking change kicked off the 2.x cycle. Basides that PR, also the removal of support for the OPAM 1.2.x client was merged.

Marek has rebased the removal of the bistro command to work on Cmdliner 1.1.0 and it is ready to be reviewed. A similar PR to remove support for the OPAM 1.0 file format is to follow.

There was a follow-up to the discussion about reducing our reliance on binaries (for portability and easier integration with the platform tool):

• opam is only used for linting and it was agreed that rewriting the linter to call the relavant part of the library should be attempted. #430 exists to track this.
• We use tar only to unpack tarballs (#432) and we should remove it, as well as bzip2 for packing (#433) tarballs
• Removing curl could be difficult since putting Cohttp everywhere would change the API quite a bit and is probably the last to go #434
• No plans to replace git so far.

These can happen at any time and aren't blockers for a 2.0 release. They can also happen incrementally. It was agreed that Marek will create tracking issues for this (happened hereby, see linked ticket numbers).

@gpetiot created #431 and we agreed that this is the way forward, it is to be reviewed and merged. By dropping dune-project we don't have a need for a sexp-parser anymore thus can push the idea of revisiting the config format a bit into the future.

@NathanReb mentioned that many of the breaking changes are small and could be implemented quickly without much re-engineering of the project, so a 2.0 release could happen soon, with the future improvements (#430, #432, #433, #434, #409, etc etc) not being breaking changes and can happen as part of 2.1, 2.2, etc.

There was a discussion about doc fields. Currently dune-release generates documentation using odoc if there is a doc field. Yet if the doc field does not point to Github pages then it fails in annoying ways that prevent people from making releases. Also, the way it generates the documentation is suboptimal because it does not version the URLs and given it is a release tool it doesn't handle the generation of documentation of the current development branch. Marek mentioned that it is difficult to detect github pages in doc because one can use custom domains for it. Also Github supports Github Pages using different methods than gh-pages branches so if the user has set this up differently it already doesn't work.

Nathan suggested changing the default to not generate pages and making it opt-in to generate documentation while releasing so people who used this functionality still can use it. Given the V3 website will handle generation of docs on its side in a much better way than what dune-release does we assume that as time goes on it will be preferable to have the documentation on the V3 site than in Github Pages. Nathan also suggested that we could create an Github Action that would generate the documentation from the development branch on every push, so people who used Github Pages can keep publishing their documentation and use the Github pages in a more reasonable way.