Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update making releases page post 6.4 #10932

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 71 additions & 21 deletions doc/sphinx-guides/source/developers/making-releases.rst
Original file line number Diff line number Diff line change
Expand Up @@ -10,10 +10,43 @@ Introduction

This document is about releasing the main Dataverse app (https://github.com/IQSS/dataverse). See :doc:`making-library-releases` for how to release our various libraries. Other projects have their own release documentation.

The steps below describe making both regular releases and hotfix releases.

Below you'll see branches like "develop" and "master" mentioned. For more on our branching strategy, see :doc:`version-control`.

Regular or Hotfix?
------------------

Early on, make sure it's clear what type of release this is. The steps below describe making both regular releases and hotfix releases.

- regular

- e.g. 6.5 (minor)
- e.g. 7.0 (major)

- hotfix

- e.g. 6.4.1 (patch)
- e.g. 7.0.1 (patch)

Ensure Issues Have Been Created
-------------------------------

In advance of a release, GitHub issues should have been created already that capture certain steps. See https://github.com/IQSS/dataverse-pm/issues/335 for examples.

Declare a Code Freeze
---------------------

The following steps are made more difficult if code is changing in the "develop" branch. Declare a code freeze until the release is out. Do not allow pull requests to be merged.

Conduct Performance Testing
---------------------------

See :doc:`/qa/performance-tests` for details.

Conduct Smoke Testing
---------------------

See :doc:`/qa/testing-approach` for details.

.. _write-release-notes:

Write Release Notes
Expand All @@ -23,26 +56,46 @@ Developers express the need for an addition to release notes by creating a "rele

The task at or near release time is to collect these snippets into a single file.

- Create an issue in GitHub to track the work of creating release notes for the upcoming release.
- Find the issue in GitHub that tracks the work of creating release notes for the upcoming release.
- Create a branch, add a .md file for the release (ex. 5.10.1 Release Notes) in ``/doc/release-notes`` and write the release notes, making sure to pull content from the release note snippets mentioned above. Snippets may not include any issue number or pull request number in the text so be sure copy the number from the filename of the snippet into the final release note.
- Delete (``git rm``) the release note snippets as the content is added to the main release notes file.
- Include instructions describing the steps required to upgrade the application from the previous version. These must be customized for release numbers and special circumstances such as changes to metadata blocks and infrastructure.
- Take the release notes .md through the regular Code Review and QA process. That is, make a pull request.
- Take the release notes .md through the regular Code Review and QA process. That is, make a pull request. Here's an example: https://github.com/IQSS/dataverse/pull/10866

Create a GitHub Issue and Branch for the Release
------------------------------------------------
Deploy Release Candidate to Demo
--------------------------------

First, build the release candidate.

ssh into the dataverse-internal server and undeploy the current war file.

Go to https://jenkins.dataverse.org/job/IQSS_Dataverse_Internal/ and make the following adjustments to the config:

- Repository URL: ``https://github.com/IQSS/dataverse.git``
- Branch Specifier (blank for 'any'): ``*/develop``
- Execute shell: Update version in filenames to ``dataverse-5.10.war`` (for example)

Click "Save" then "Build Now".

This will build the war file, and then automatically deploy it on dataverse-internal. Verify that the application has deployed successfully.

You can scp the war file to the demo server or download it from https://jenkins.dataverse.org/job/IQSS_Dataverse_Internal/ws/target/

ssh into the demo server and follow the upgrade instructions in the release notes.

Prepare Release Branch
----------------------
Comment on lines +86 to +87
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "prepare release branch" step the new name for "bump version numbers".

These days are extra steps related to containers, hence the name change.


The release branch will have the final changes such as bumping the version number.

Usually we branch from the "develop" branch to create the release branch. If we are creating a hotfix for a particular version (5.11, for example), we branch from the tag (e.g. ``v5.11``).

Use the GitHub issue number and the release tag for the name of the branch. (e.g. ``8583-update-version-to-v5.10.1``
Create a release branch named after the issue that tracks bumping the version with a descriptive name like "10852-bump-to-6.4" from https://github.com/IQSS/dataverse/pull/10871.

**Note:** the changes below must be the very last commits merged into the develop branch before it is merged into master and tagged for the release!

Make the following changes in the release branch.

Bump Version Numbers and Prepare Container Tags
-----------------------------------------------

Increment the version number to the milestone (e.g. 5.10.1) in the following two files:

- modules/dataverse-parent/pom.xml -> ``<properties>`` -> ``<revision>`` (e.g. `pom.xml commit <https://github.com/IQSS/dataverse/commit/3943aa0>`_)
Expand All @@ -58,14 +111,11 @@ Return to the parent pom and make the following change, which is necessary for p

(Before you make this change the value should be ``${parsedVersion.majorVersion}.${parsedVersion.nextMinorVersion}``. Later on, after cutting a release, we'll change it back to that value.)

Check in the Changes Above into a Release Branch and Merge It
-------------------------------------------------------------

For a regular release, make the changes above in the release branch you created, make a pull request, and merge it into the "develop" branch. Like usual, you can safely delete the branch after the merge is complete.

If you are making a hotfix release, make the pull request against the "master" branch. Do not delete the branch after merging because we will later merge it into the "develop" branch to pick up the hotfix. More on this later.

Either way, as usual, you should ensure that all tests are passing. Please note that you will need to bump the version in `jenkins.yml <https://github.com/GlobalDataverseCommunityConsortium/dataverse-ansible/blob/develop/tests/group_vars/jenkins.yml>`_ in dataverse-ansible to get the tests to pass. Consider doing this before making the pull request. Alternatively, you can bump jenkins.yml after making the pull request and re-run the Jenkins job to make sure tests pass.
Either way, as usual, you should ensure that all tests are passing. Please note that you will need to bump the version in `jenkins.yml <https://github.com/gdcc/dataverse-ansible/blob/develop/tests/group_vars/jenkins.yml>`_ in dataverse-ansible to get the tests to pass. Consider doing this before making the pull request. Alternatively, you can bump jenkins.yml after making the pull request and re-run the Jenkins job to make sure tests pass.

Merge "develop" into "master"
-----------------------------
Expand Down Expand Up @@ -94,7 +144,7 @@ After the "master" branch has been updated and the GitHub Action to build and pu

To test these images against our API test suite, go to the "alpha" workflow at https://github.com/gdcc/api-test-runner/actions/workflows/alpha.yml and run it.

If there are failures, additional dependencies or settings may have been added to the "develop" workflow. Copy them over and try again.
Don't be surprised if there are failures. The test runner is a work in progress! Additional dependencies or settings may have been added to the "develop" workflow. Copy them over and try again.

.. _build-guides:

Expand Down Expand Up @@ -186,11 +236,6 @@ Upload the following artifacts to the draft release you created:
- metadata block tsv files
- config files

Deploy on Demo
--------------

Now that you have the release ready to go, consider giving it one final test by deploying it on https://demo.dataverse.org. Note that this is also an opportunity to re-test the upgrade checklist as described in the release note.

Publish the Release
-------------------

Expand Down Expand Up @@ -228,7 +273,12 @@ Create a new branch (any name is fine but ``prepare-next-iteration`` is suggeste

Now create a pull request and merge it.

For more background, see :ref:`base-supported-image-tags`.
For more background, see :ref:`base-supported-image-tags`. For an example, see https://github.com/IQSS/dataverse/pull/10896

Deploy Final Release on Demo
----------------------------
Comment on lines +278 to +279
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved the final deploy to demo down, after the release, because I added a "deploy release candidate to demo" step pretty early in the process.


Above you already did the hard work of deploying a release candidate to https://demo.dataverse.org. It should be relatively straightforward to undeploy the release candidate and deploy the final release.

Add the Release to the Dataverse Roadmap
----------------------------------------
Expand Down
Loading