Skip to content

Release 2.3.0

Prerequisites

  • Make sure that the current VTK-m release branch builds in VTK.
  • Make sure that the current VTK-m release branch builds in ECP Ascent.

Update VTK-m

  • Update release branch for vtk-m and create update branch
git fetch origin
git checkout release
git merge --ff-only origin/release
git submodule update --recursive --init

Create update branch

  • Freeze the release branch (In Gitlab VTK-m page)
    • Settings/Repository/Protected Branches: Release; "allowed to push:No one"
  • Create update branch git checkout -b update-to-2.3.0
  • Backport merge-requests belonging to the milestone 2.3.0
  • Set version to master
echo "2.3.9999" > version.txt
git add version.txt
  • Update the version (not in patch releases) and date in the LICENSE.md file git add LICENSE.md.
  • Create commit that updates the License (and version.txt if modified):
git commit -m 'release: update version and License'
  • Craft or update changelog docs/changelog/2.3.0/release-notes.md file.
  • Create release notes commit.
git add docs/changelog/2.3/release-notes.md
git rm docs/changelog/*.md
git commit -m 'release: 2.3.0 release notes'
  • Create update version commit:
echo 2.3.0 > version.txt
git add version.txt

# Create commit with the following template
# Nth is counted by the number of final release tags
git commit -m '2.3.0 is our Nth official release of VTK-m.

The major changes to VTK-m from (previous release) can be found in:
  docs/changelog/2.3.0/release-notes.md' version.txt
  • git tag -a -m 'VTKm 2.3.0' v2.3.0 HEAD
  • Integrate changes to release branch
    • Create a MR using the release-mr script (see notes).
    • Add (or ensure) at the bottom of the description of the merge request: Backport: master:HEAD~1
    • Get +1
    • Do: merge
    • Push tags
      • git push origin v2.3.0
  • Unfreeze the release branch (In Gitlab VTK-m page)
    • Settings/Repository/Protected Branches: Release; "allowed to push: Maintainers"

Update Packages

Post-release

  • Copy the contents of docs/changelog/2.3.0/release-notes.md to the GitLab release.
  • Tag new version of the VTK-m User Guide.
  • Post an Email Announcements VTK-m mailing list.
  • Ensure that the content of version.txt in master is 2.3.9999.

Update VTK-m in VTK

VTK ships a particular VTK-m release in each of its releases, we need to open a merge-request update the VTK-m commit in VTK as soon as possible even if the newly VTK-m version does not correspond with the scheduled for the following VTK release, the reason for opening the merge-request is that:

  • We can test how compatible it is with VTK giving us the change to address those issues in the following releases.
    • We do not forget to update VTK-m commit in VTK when the time comes
  • Update VTK-m submodule in VTK using: git submodule update --remote

Annex

Generate change log

Construct a docs/changelog/2.3.0/ folder. Construct a docs/changelog/2.3.0/release-notes.md file

Use the following template for release-notes.md:

VTK-m N Release Notes
=======================

<!-- if is a patch release -->

| Merge request description                                           | Merge request id |
| ------------------------------------------------------------------- | ---------------- |
| Update the link to register with the VTK-m dashboard                | !2629            |
.
.
.
| CMAKE: CUDA ampere generate sm_80/86                                | !2688            |

<!-- else -->

# Table of Contents
1. [Core](#Core)
    - Core change 1
2. [ArrayHandle](#ArrayHandle)
3. [Control Environment](#Control-Environment)
4. [Execution Environment](#Execution-Environment)
5. [Worklets and Filters](#Worklets-and-Filters)
6. [Build](#Build)
7. [Other](#Other)

<!-- endif -->
# Core

## Core change 1 ##

changes in core 1

# ArrayHandle

# Control Enviornment

# Execution Environment

# Execution Environment

# Worklets and Filters

# Build


# Other

For each individual file in docs/changelog move them to the relevant release-notes section.

  • Make sure each title and entry in the table of contents use full vtkm names vtkm::cont::Field instead of Field.
  • Make sure each title and entry DOESN'T have a period at the end.
  • Make sure any sub-heading as part of the changelog is transformed from ## to ###.
  • Entries for Core are reserved for large changes that significantly improve VTK-m users life, or are major breaking changes.

Notes about update-mr

update-mr script has the following requirements to work:

  1. It needs a token to for authentication (reach @ben.boeckel for this)
  2. It needs kwrobot.release.vtkm to have developer perms in your vtk-m repo.

Lastly, update-mr can be used multiple times with different commit in the same branch.

Notes about version.txt

Master and release branch do not share the same version.txt scheme. In the release branch the patch and release-candidate version is observed whereas in master the patch field is fixed to 9999 indicating that each of its commit is a developing release.

  • Master: 2.3.9999
  • Release: 2.3.0

Email Announcements

Announce the new VTK-m release on the mailing list. You will need to compute the number of merge requests, changelog entries, and maybe # of authors.

Example to compute the number of unique committers

git log --format="%an" v1.4.0..v1.5.0 | sort -u | wc -l

Example to compute the number of merge requests

git log v2.0.0..v2.1.0 | grep 'Merge topic' | wc -l

A standard template to use is:

Hi All,

VTK-m 1.5.0 is now released, and a special thanks to everyone that has
contributed to VTK-m since our last release. The 1.5.0 release contains
over 100000 merge requests, and 100000 entries to the changelog .

Below are all the entries in the changelog, with more details at (
https://gitlab.kitware.com/vtk/vtk-m/-/tags/v2.3.0) or in the vtkm
repository at `docs/2.3.0/release-notes.md`

1. Core
    - Core change 1
2. ArrayHandle
3. Control Environment
4. Execution Environment
5. Worklets and Filters
6. Build
7. Other

@ben.boeckel
@vbolea

Edited by Vicente Bolea