LDD Release Process

When a Sub-Model Steward is ready to submit a new version of an LDD for release you have two options:

Release

Nominal Development and Release

The ideal workflow for tagging a release happens every 6 months in line with the PDS4 Build Schedule. Here is the process:

1. Develop

Responsible Party: Sub-Model Steward

In between build cycles, you are free to develop/enhance/upgrade your sub-model, making sure to update the sub-model version as appropriate and all your updates are merged into the main branch.

2. Wait

Responsible Party: Sub-Model Steward

If you have completed development, you do not need to do anything else to prepare or tag your release. This will be done later by Engineering Node automation. See Key Dates for more information on timeframe for release.

3. Staging Nominal Release

Responsible Party: Engineering Node

EN will “stage the release” of the sub-model by automatically generating a Pull Request on your repository. The Pull Request will include an update to include the latest PDS4 Information Model version, all schemas/schematrons will be regenerated and tests executed via the Sub-Model Automation.

4. Review and Merge Pull Request

Responsible Party: Sub-Model Steward

Once you receive notification of the staged release, it is the responsibility of the Sub-Model Steward to:

  1. Review the pull request - the Sub-Model Steward and associated Stewardship Team (as applicable) should review the regression tests passed as expected, and the schemas/schematrons generated are correct.

  2. Merge the pull request - merge the pull request to automatically tag a new version of the sub-model in GitHub.

Note

If the Sub-Model Steward does not merge the pull request, the sub-model will not be released with the latest version of the Information Model. Text will be included on the web page notifying users they can submit a request that a new version be produced.

5. Deploy Nominal Release

Responsible Party: Engineering Node

On the PDS System Release Date, EN will pull all the tagged releases from all the repos, generate the applicable web pages, and release all of the sub-models online.

Note

Only the version of the sub-model associated with the new PDS4 Information Model will be included in the final “Deploy Nominal Release” step. A separate Release Request is required for any past version(s) of the sub-model you would like released.*

Off-Nominal Release

Note

Please try to avoid this wherever possible. In order to minimize overhead of manual processing of sub-models, please coordinate with data providers to stick to the PDS4 Build Schedule wherever posisble.

At any time, you can direct providers to the build/development directory of your Sub-Model repository in order for them to have immediate access to the dictionaries for development and testing purposes.

If an immediate bug fix and release is needed off PDS4 Build cycle, see the Preparing a Release for instructions for how to tag a release.

Preparing a Release

Check Github for Tagged Released

Before you tag a release in Github, verify the version you would like released has not already been tagged by EN Automation.

  1. Go to your repo’s release page, e.g. https://github.com/pds-data-dictionaries/ldd-img/releases.

  2. If the version you would like released appears in the list, proceed to Submit Release Request, otherwise proceed to “Tag a Release in Github”.

Tag a Release In Github

  1. Add your IngestLDD to the src/ directory in your repo

  2. Create a branch with release in the name, e.g. release/1.18.0.0_1.1.0.0

  3. If the intent is to release a sub-model with a past PDS4 Information Model version, see documentation for Changing PDS4 Build Versions.

  4. Add your changes to the branch, commit, and push branch to Github. Be sure to push your branch even if you have no changes to commit.

  5. If you have no changes, or you changes are not to your IngestLDD file, you will need to manually trigger the build of the LDDs:

    1. Select the Actions tab

    2. Under the Actions left sidebar, select PDS4 Sub-Model Automation

    3. From the blue row in the table, select the Run Workflow dropdown.

    4. Select your branch from the dropdown.

    5. Select the Run Workflow button.

../_images/screenshot-workflow-dispatch.png

  1. Create a Pull Request for your branch.

  2. Optional: monitor the generation of the dictionaries via the Actions tab in your Github repository.

  3. Once the build completes, you should see the new LDD auto-generated (after ~2-3 minutes) in both the build/development and build/release directories.

  4. Once you get approval from the appropriate stakeholders, merge your pull request.

  5. You should then see a new release tagged in your repo in a URL like https://github.com/pds-data-dictionaries/ldd-img/releases

  6. Then move on to Submit Release Request below to submit ticket to the EN Operations Github repo.

Submit Release Request

Submit a PDS LDD Release request request ticket here.

Reviewing a Staged Release

See the Review a Pull Request How-to