You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/sphinx-guides/source/developers/making-releases.rst
+29-65Lines changed: 29 additions & 65 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,30 +93,29 @@ Developers express the need for an addition to release notes by creating a "rele
93
93
The task at or near release time is to collect these snippets into a single file.
94
94
95
95
- Find the issue in GitHub that tracks the work of creating release notes for the upcoming release.
96
-
- 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 to copy the number from the filename of the snippet into the final release note.
96
+
- Create a branch, add a .md file for the release (ex. 6.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 to copy the number from the filename of the snippet into the final release note.
97
97
- Delete (``git rm``) the release note snippets as the content is added to the main release notes file.
98
98
- 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. These instructions are required for the next steps (deploying to various environments) so try to prioritize them over finding just the right words in release highlights (which you can do later).
99
99
- Make a pull request. Here's an example: https://github.com/IQSS/dataverse/pull/11613
100
100
- Note that we won't merge the release notes until after we have confirmed that the upgrade instructions are valid by performing a couple upgrades.
101
101
102
102
For a hotfix, don't worry about release notes yet.
103
103
104
-
Deploy Release Candidate to Internal
105
-
------------------------------------
104
+
Build Release Candidate
105
+
-----------------------
106
106
107
107
|dedicated|
108
108
109
109
First, build the release candidate. For a regular release, you will use the "develop" branch, as shown below. For a hotfix, you will use whatever branch name is used for the hotfix.
110
110
111
-
Go to https://jenkins.dataverse.org/job/IQSS_Dataverse_Internal/ and make the following adjustments to the config:
111
+
Go to https://github.com/IQSS/dataverse/actions/workflows/generate_war_file.yml click "run workflow". Make sure the branch is "develop". Leave the custom label blank and click "run workflow". This will create an action that should result in a zip file. Inside that zip is another zip that contains the war file.
- Branch Specifier (blank for 'any'): ``*/develop``
115
-
- Execute shell: Update version in filenames to ``dataverse-5.10.war`` (for example)
113
+
Deploy Release Candidate to Internal
114
+
------------------------------------
116
115
117
-
Click "Save" then "Build Now". The release candidate war file will be available at https://jenkins.dataverse.org/job/IQSS_Dataverse_Internal/ws/target/
116
+
|dedicated|
118
117
119
-
ssh into the dataverse-internal server and download the release candidate war file from the URL above.
118
+
ssh into the dataverse-internal server and download the release candidate war file you built above.
120
119
121
120
Go to /doc/release-notes, open the release-notes.md file for the release we're working on, and perform all the steps under "Upgrade Instructions". Note that for regular releases, we haven't bumped the version yet so you won't be able to follow the steps exactly. (For hotfix releases, the version will be bumped already.)
122
121
@@ -197,7 +196,7 @@ Create a release branch named after the issue that tracks bumping the version wi
197
196
198
197
Make the following changes in the release branch.
199
198
200
-
Increment the version number to the milestone (e.g. 5.10.1) in the following two files:
199
+
Increment the version number to the milestone (e.g. 6.10.1) in the following two files:
@@ -243,7 +242,7 @@ If the GitHub UI tells you there would be merge conflicts, something has gone ho
243
242
Add Milestone to Pull Requests and Issues
244
243
-----------------------------------------
245
244
246
-
Often someone is making sure that the proper milestone (e.g. 5.10.1) is being applied to pull requests and issues, but sometimes this falls between the cracks.
245
+
Often someone is making sure that the proper milestone (e.g. 6.10.1) is being applied to pull requests and issues, but sometimes this falls between the cracks.
247
246
248
247
Check for merged pull requests that have no milestone by going to https://github.com/IQSS/dataverse/pulls and entering `is:pr is:merged no:milestone <https://github.com/IQSS/dataverse/pulls?q=is%3Apr+is%3Amerged+no%3Amilestone>`_ as a query. If you find any, first check if those pull requests are against open pull requests. If so, do nothing. Otherwise, add the milestone to the pull request and any issues it closes. This includes the "merge develop into master" pull request above.
249
248
@@ -267,86 +266,51 @@ Go to https://jenkins.dataverse.org/job/guides.dataverse.org/ and make the follo
- Branch Specifier (blank for 'any'): ``*/master``
270
-
- ``VERSION`` (under "Build Steps"): bump to the next release. Don't prepend a "v". Use ``5.10.1`` (for example)
269
+
- ``VERSION`` (under "Build Steps"): bump to the next release. Don't prepend a "v". Use ``6.10.1`` (for example)
271
270
272
271
Click "Save" then "Build Now".
273
272
274
-
Make sure the guides directory appears in the expected location such as https://guides.dataverse.org/en/5.10.1/
273
+
Make sure the guides directory appears in the expected location such as https://guides.dataverse.org/en/6.10.1/
275
274
276
275
As described below, we'll soon point the "latest" symlink to that new directory.
277
276
278
-
Create a Draft Release on GitHub
279
-
--------------------------------
280
-
281
-
Go to https://github.com/IQSS/dataverse/releases/new to start creating a draft release.
282
-
283
-
- Under "Choose a tag" you will be creating a new tag. Have it start with a "v" such as ``v5.10.1``. Click "Create new tag on publish".
284
-
- Under "Target", choose "master". This commit will appear in ``/api/info/version`` from a running installation.
285
-
- Under "Release title" use the same name as the tag such as ``v5.10.1``.
286
-
- In the description, copy and paste the content from the release notes .md file created in the "Write Release Notes" steps above.
287
-
- Click "Save draft" because we do not want to publish the release yet.
288
-
289
-
At this point you can send around the draft release for any final feedback. Links to the guides for this release should be working now, since you build them above.
290
-
291
-
Make corrections to the draft, if necessary. It will be out of sync with the .md file, but that's ok (`#7988 <https://github.com/IQSS/dataverse/issues/7988>`_ is tracking this).
292
-
293
277
.. _run-build-create-war:
294
278
295
279
Run a Build to Create the War File
296
280
----------------------------------
297
281
298
-
ssh into the dataverse-internal server and undeploy the current war file.
282
+
Go to https://github.com/IQSS/dataverse/actions/workflows/generate_war_file.yml click "run workflow". For a regular release, change the branch to "master". For a hotfix release, use whatever branch name is used for the hotfix. Leave the custom label blank and click "run workflow". This will create an action that should result in a zip file. Inside that zip is another zip that contains the war file.
299
283
300
-
Go to https://jenkins.dataverse.org/job/IQSS_Dataverse_Internal/ and make the following adjustments to the config:
- Branch Specifier (blank for 'any'): ``*/master``
304
-
- Execute shell: Update version in filenames to ``dataverse-5.10.1.war`` (for example)
305
-
306
-
Click "Save" then "Build Now".
307
-
308
-
This will build the war file, and then automatically deploy it on dataverse-internal. Verify that the application has deployed successfully.
309
-
310
-
The build number will appear in ``/api/info/version`` (along with the commit mentioned above) from a running installation (e.g. ``{"version":"5.10.1","build":"907-b844672``).
311
-
312
-
Note that the build number comes from the following script in an early Jenkins build step...
... but we can explore alternative methods of specifying the build number, as described in :ref:`auto-custom-build-number`.
284
+
The build number will appear in ``/api/info/version`` (along with the commit mentioned above) from a running installation (e.g. ``{"version":"6.10.1","build":"master-300d5b5"}``).
320
285
321
286
Build Installer (dvinstall.zip)
322
287
-------------------------------
323
288
324
-
ssh into the dataverse-internal server and do the following:
325
-
326
289
- In a git checkout of the dataverse source switch to the master branch and pull the latest.
327
290
- Copy the war file from the previous step to the ``target`` directory in the root of the repo (create it, if necessary):
328
291
- ``mkdir target``
329
-
- ``cp /tmp/dataverse-5.10.1.war target``
292
+
- ``cp /tmp/dataverse-6.10.1.war target``
330
293
- ``cd scripts/installer``
331
294
- ``make clean``
332
295
- ``make``
333
296
334
297
A zip file called ``dvinstall.zip`` should be produced.
335
298
336
-
Alternatively, you can build the installer on your own dev. instance. But make sure you use the war file produced in the step above, not a war file build from master on your own system! That's because we want the released application war file to contain the build number described above. Download the war file directly from Jenkins, or from dataverse-internal.
299
+
Create a Draft Release on GitHub
300
+
--------------------------------
337
301
338
-
Make Artifacts Available for Download
339
-
-------------------------------------
302
+
Go to https://github.com/IQSS/dataverse/releases/new to start creating a draft release.
340
303
341
-
Upload the following artifacts to the draft release you created:
304
+
- Under "Select tag" you will be creating a new tag. Have it start with a "v" such as ``v6.10.1``. Click "Create new tag". Don't worry, this won't happen until you publish.
305
+
- Under "Target", choose "master". This commit will appear in ``/api/info/version`` from a running installation.
306
+
- Under "Release title" use the same name as the tag such as ``v6.10.1``.
307
+
- In the description, copy and paste the content from the release notes .md file created in the "Write Release Notes" steps above.
308
+
- Under "attach binaries", upload the war file and installer you created above.
309
+
- Click "Save draft" because we do not want to publish the release yet.
342
310
343
-
- the war file (e.g. ``dataverse-5.10.1.war``, from above)
344
-
- the installer (``dvinstall.zip``, from above)
345
-
- other files as needed:
311
+
At this point you can send around the draft release for any final feedback. Links to the guides for this release should be working now, since you build them above.
346
312
347
-
- updated Solr schema
348
-
- metadata block tsv files
349
-
- config files
313
+
Make corrections to the draft, if necessary. It will be out of sync with the .md file, but that's ok (`#7988 <https://github.com/IQSS/dataverse/issues/7988>`_ is tracking this).
350
314
351
315
Publish the Release
352
316
-------------------
@@ -356,14 +320,14 @@ Click the "Publish release" button.
356
320
Update Guides Link
357
321
------------------
358
322
359
-
"latest" at https://guides.dataverse.org/en/latest/ is a symlink to the directory with the latest release. That directory (e.g. ``5.10.1``) was put into place by the Jenkins "guides" job described above.
323
+
"latest" at https://guides.dataverse.org/en/latest/ is a symlink to the directory with the latest release. That directory (e.g. ``6.10.1``) was put into place by the Jenkins "guides" job described above.
360
324
361
325
ssh into the guides server and update the symlink to point to the latest release, as in the example below.
362
326
363
327
.. code-block:: bash
364
328
365
329
cd /var/www/html/en
366
-
ln -s 5.10.1 latest
330
+
ln -s 6.10.1 latest
367
331
368
332
This step could be done before publishing the release if you'd like to double check that links in the release notes work.
369
333
@@ -374,7 +338,7 @@ You can find our milestones at https://github.com/IQSS/dataverse/milestones
374
338
375
339
Now that we've published the release, close the milestone and create a new one for the **next** release, the release **after** the one we're working on, that is.
376
340
377
-
Note that for milestones we use just the number without the "v" (e.g. "5.10.1").
341
+
Note that for milestones we use just the number without the "v" (e.g. "6.10.1").
378
342
379
343
On the project board at https://github.com/orgs/IQSS/projects/34 edit the tab (view) that shows the milestone to show the next milestone.
0 commit comments