---
# System prepended metadata

title: Preparations for v3.0.0 release
tags: [DUNE-DAQ]

---

# Preparations for v3.0.0 release

###### tags: `DUNE-DAQ`

## General info

### Important dates

- **Release date: Tuesday, 24 May**
- ***Tag collection date: Wednesday, 18 May***

```mermaid
gantt
    title dunedaq-v3.0.0 release cycle option 1
    dateFormat  MM-DD
    excludes    weekends
    section Option 1
    Unified API        :crit, active, a1, 2022-04-29, 6d
    Preparing for tags :active, a2, 2022-04-29, 14d
    Beta testing       :  a3, after a2, 4d
    Next relase cycle ...  :  a4, after a3, 19d
```

Assess on 11 May, one week before 18 May, to decide if more time is needed.
- **Release date: Wednesday, 8 June**
- ***Tag collection date: 24 May***

```mermaid
gantt
    title dunedaq-v3.0.0 release cycle option 2
    dateFormat  MM-DD
    excludes    weekends
    section Option 2
    Unified API        :crit, active, a1, 2022-04-29, 6d
    Preparing for tags :active, a2, 2022-04-29, 18d
    Beta testing       :  a3, after a2, 11d
    Next relase cycle ... :  a4, after a3, 8d
```

### Useful links for progress tracking

* [Task list (spreadsheet)](https://docs.google.com/spreadsheets/d/1q-aWGE42HWq0U6Cns2xQfGpxpBKQsgCIF8KxFdRsa5s/edit?usp=sharing)
* [High-level tasks in `daq-deliverables`](https://github.com/DUNE-DAQ/daq-deliverables/issues)
* [DUNE DAQ tracking project on GitHub](https://github.com/orgs/DUNE-DAQ/projects/5/views/11)
* [Tag Collector](https://docs.google.com/spreadsheets/d/1yPNWi11mpVNB_TaaNvQZuzVSt3k9S34a1sUFM_WBHfk/edit#gid=1652289508)
* [dunedaq-v3.0.0 Testing](https://docs.google.com/spreadsheets/d/1M0izRNNuv1pHVBbMfo4BPeCB3z_-MBFdNUgIS_vSPho/edit#gid=1167859878)

### Branch merge rules

* features targeted for the current `v3.0.0` release shall be merged to the develop branch
* features targeted for future releases shall **NOT** be merged into the develop branch yet, but can be merged to `release-prep/dunedaq-v3.1.0`. SW Coordination team can make the mass merge across repos when `v3.1.0` release cycle begins.

### Project fields and labels

* New issues and PRs will be automatically linked to the tracking project;
* Please set Project fields whenever possible:
    * **Mandatory fields:** `Status, Target Release, Working Group`
    * Optional fields: `Priority, Target Date, External Impact`
![Set project fields](https://i.imgur.com/b3vqOXQ.gif)
* Please assign labels to issues and PRs as much as possible:
    * issues in `daq-deliverables` should include the "deliverable" label;
    * issues/PRs in code repositories can have the following labels:
        * `feature, bug, documentation, enhancement, wontfix, help wanted`
* Creating associated issues for PR is not mandatory, however, PRs should be linked to issues if they are associated;
![Link issues to PRs](https://i.imgur.com/Zak1mJU.gif)
* Normally, an issues in the `daq-deliverable` repository maps to a high level tasks in the task spreadsheet. Whenever possible, please update/comment on the issue in `daq-deliverables` with links of associated issues and PRs in code repositories.


### Tagging procedure

* Branch protection rule on the develop branch for all repositories:
    * no direct pushes allowed;
    * Pull requests must be aproved before getting merged.
* The change of protection rules requires the following new tagging procedure:
    1. `git checkout develop # checkout develop HEAD`;
    2. `git checkout -b prep-release/dunedaq-v3.0.0 #creating new branch from develop HEAD`;
    3. Bump verson number in `CMakeLists.txt` (in `setup.py` or `__init__.py` etc for python packages);
    4. `git tag -a <vX.X.X> # create annotated tag <vX.X.X>` on the PR branch;
    5. Update [Tag Collector](https://docs.google.com/spreadsheets/d/1yPNWi11mpVNB_TaaNvQZuzVSt3k9S34a1sUFM_WBHfk/edit#gid=1652289508) with the new tag;
    6. Create PR for this branch against the develop branch;
    7. Another developer or Software Coordination team member approve and merge the PR; alternatively, you can use the `auto approve` GitHub Action to add a dummy approval to the PR (instructions can be found below).
* Note 1: the new tag is created on the PR branch once the version number is bumped; it does not need to wait for the review/merge of the PR.
* Note 2: new PRs will be added to the [DUNE DAQ tracking project on GitHub](https://github.com/orgs/DUNE-DAQ/projects/5/views/11) automatically. But the fields (status, target release, working group as a minimum) need to be set properly by hand. 


### Adding dummy approval to a pull request

In case of simple code changes where a reviewer is not needed, one can bypass the review requirement by using GitHub Action to add a dummy approval. The steps are:
1. Go to the `Actions` tab of the repository;
2. Select the "Auto approve" workflow;
3. Click `Run workflow`, put in the pull request number for which the dummy approval should be added and run the workflow;
4. An approval from the user "github-actions" will appear on the PR once the workflow finished running (in about ~4 seconds).

![](https://i.imgur.com/jqwznbh.gif)

## Candidate releases

* Candidate releases have their names in the form of `rc-<dunedaq-release-name>-<N>`;
* They are deployed under `/cvmfs/dunedaq-development.opensciencegrid.org/candidate-releases`;
* The latest version of `dbt-buildtools` for spack has been updated to support candidate releases (use `setup_dbt latest-spack`).
* To create a workarea based on a candidate release, add `-b candidate` to the `dbt-create` command, i.e. `dbt-create -b candidate <candidate_release_name> <workarea_dir>` (similarly `dbt-create -l -b candidate` will list all the available candidate releases). More details can be found [here](https://github.com/DUNE-DAQ/daq-buildtools#creating-a-work-area) (`docs/README.md` in `daq-buildtools`);
* `dbt-setup-release` also supports candidate releases, similar to `dbt-create`, add `-b candidate` to the command when using candidate releases.

### Candidate releases for dunedaq-v3.0.0

* A new tab has been created in the tag collector, listing the tags used for each candidate release in the release cycle of `dunedaq-v3.0.0`; additionally, there is a column for the next candidate release. When putting in updating a tag in the "3.X" tab, it will be good to have it reflected in this column too. I will also check the "3.X" tab before each build.
* At the moment, `rc-dunedaq-v3.0.0-3` is the first candidate release after we collected all the tags. Please ignore `rc-dunedaq-v3.0.0-1` and `rc-dunedaq-v3.0.0-2`. They were used for workflow testing.

### Example usage of `rc-dunedaq-v3.0.0-3`

```bash=
source /cvmfs/dunedaq.opensciencegrid.org/setup_dunedaq.sh
setup_dbt latest-spack

# To list all available candidate releases
dbt-create -b candidate -l 
# To create a workarea "myWorkDir" based on the candidate release
dbt-create -b candidate -c rc-dunedaq-v3.0.0-3 myWorkDir_rc3
```


## Release Preparation Meetings

- Time: 07:30 Fermilab, 13:30 UK, 14:30 CERN.
- [Zoom link](https://fnal.zoom.us/j/99610245582)
- [Indico page](https://indico.fnal.gov/event/54600/)

