---
# System prepended metadata

title: Untitled

---

`# Releasing `privacy-team`  on opam

1. Check that the dependencies listed for each project in `dune-project`  are still consistent with what is declared in each `dune` file. Bump the version in `dune-project`, run `dune build` to update all `.opam` files. Update `.build_system_hash`. Merge to master.

2. Choose the commit in master that will be released. Check it out locally and create a tag with the name of the release, e.g.
    ```
    git tag -s v0.1.2 -m "tezos-bls12-381-polynomial, tezos-plompiler, tezos-plonk"
    git push origin v0.1.2 
    ```
    (Note: you can use `git tag -a` if you don't want to sign the tag.)

3. On https://gitlab.com/nomadic-labs/privacy-team/-/releases, click "New release". Select the tag, fill in the title and notes and click "Create release". It should now appear on the releases page. Copy the link marked "Source code (tar.gz)".

4. Run `opam publish` with the link from above. The tool takes your code archive, creates the `opam` files that are included in opam-repository (slightly different from the `*.opam` files in the repo) and opens a pull request for you on the official opam-repository repo. Example: `opam publish https://gitlab.com/nomadic-labs/privacy-team/-/archive/v0.1.2/privacy-team-v0.1.2.tar.gz`

    If for whatever reason you need to change the opam files generated by `opam publish`, you can instruct it to not submit directly to `opam-repository` but create a local patch which you can modify before submitting using `-o patch_name`. In the past this was useful for things like not including all the packages from `privacy-team` in the release or disabling tests by removing ``"@runtest" {with-test}`` from `build`.
    
    You can also force push to your fork any time if you need to make changes to the PR.
    
5. Once your patch pushed to your fork's `master` (either via `opam publish` or manually) you can double check that everything is working by adding the fork as an opam remote, e.g. `opam remote add victor-dumitrescu https://github.com/victor-dumitrescu/opam-repository.git`, and installing the new versions of the packages `--with-test`.

6. If you didn't use `opam publish`, open a PR on opam-repository from your fork, e.g. https://github.com/ocaml/opam-repository/pull/21732.

7. Wait for the opam CI to finish and see if there's anything that needs fixing. Once green, someone will usually merge your PR no later than the following working day. Once merged, it takes a few hours for it to be accessible via opam.

8. You'll now need to update the packages in Octez. This process is explained here: https://tezos.gitlab.io/developer/contributing-adding-a-new-opam-dependency.html