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

[INFRA] add steps for release protocol (PDF upload) #455

Merged
merged 2 commits into from
Apr 27, 2020
Merged
Changes from 1 commit
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
47 changes: 37 additions & 10 deletions Release_Protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,14 +57,14 @@ If the version preceding the `-dev` is not the target version, update the versio
In the figure below, we update `v1.2.0-dev` to `v1.2.0`.
![dev-to-stable](release_images/site_name_release_1.2dev-1.2.png "dev-to-stable")

Note: this will make our continuous integration ([CircleCI](https://circleci.com/)) fail. This fails because the URL of the new ReadTheDocs rendering has not been generated at this time. It will be generated once the GitHub release has been completed.
Note: this will make our continuous integration ([CircleCI](https://circleci.com/)) fail. This fails because the URL of the new ReadTheDocs rendering has not been generated at this time. It will be generated once the GitHub release has been completed.

Synchronize the [Contributors appendix](https://github.com/bids-standard/bids-specification/blob/master/src/99-appendices/01-contributors.md)
with the [Contributors wiki page](https://github.com/bids-standard/bids-specification/wiki/Contributors)
to ensure all contributors are duly credited.
Be sure not to remove credits if both have been edited.

Please change the previous version links from GitHub to ReadTheDocs.
Please change the previous version links from GitHub to ReadTheDocs.
In the figure below, we update v1.2.2.
![github-to-rtd](release_images/GitHub_to_RTD_spec_rendering.png "github-to-rtd")

Expand Down Expand Up @@ -118,7 +118,7 @@ $ git push rel/1.2.0

### 5. Set release date and merge

On the day of release, please ensure the release branch aligns with the master branch.
On the day of release, please ensure the release branch aligns with the master branch.
The current date should be added to/updated in the changelog in the form
YYYY-MM-DD.
The date should be placed after the link to the versioned URL.
Expand All @@ -131,7 +131,20 @@ For example:

Verify that the pull request title matches "REL: vX.Y.Z" and merge the pull request.

### 6. Tag the release
### 6. Get the built PDF

Upon each commit to the `master` branch, CircleCI builds a PDF version of the
specification (see `.circleci/config.yml` and the `pdf_build_src` directory).

So after merging the new "stable" version into `master`, wait for the CircleCI
jobs to finish and then check the built PDF using this link:

`https://circleci.com/api/v1.1/project/github/bids-standard/bids-specification/latest/artifacts/0/bids-spec.pdf?branch=master`

Download the PDF and hold it ready for upload to our Zenodo archive. See the
*Uploading the stable PDF to Zenodo* step below.

### 7. Tag the release

GitHub's release mechanism does not have all of the features we need, so manually tag the release
in your local repository.
Expand All @@ -155,7 +168,7 @@ There are four components to the tag command:
4. `upstream/master` instructs `git` to tag the most recent commit on the `master` branch of the
`upstream` remote.

### 7. Create a GitHub release
### 8. Create a GitHub release

Some GitHub processes may only trigger on a GitHub release, rather than a tag push.
To make a GitHub release, go to the [Releases
Expand All @@ -177,7 +190,7 @@ Verify ReadTheDocs builds complete and publish. If needed, manually
trigger [builds](https://readthedocs.org/projects/bids-specification/builds/)
for `stable` and the most recent tag.

### 8. Edit the mkdocs.yml file site_name to set a new development version
### 9. Edit the mkdocs.yml file site_name to set a new development version

Please submit a PR with the title `REL: <version>-dev`.
This should be the first merged PR in the new version.
sappelhoff marked this conversation as resolved.
Show resolved Hide resolved
Expand All @@ -190,10 +203,24 @@ version of the next *intended* release, followed by `-dev`.
For example, after the 1.3.0 release, either `1.3.1-dev` or `1.4.0-dev` would be reasonable, based
on the expected next version.

### 9. Sharing news of the release
### 10. Uploading the stable PDF to Zenodo

1. Open a private browser window
1. Log into https://github.com with the `bids-maintenance` user (credentials
are available from the BIDS maintainer group)
1. Open a new tab at https://zenodo.org and "log in via GitHub", you'll then
be on the `bids-maintenance` Zenodo account
1. Navigate to the [archive of our BIDS specification PDFs](https://doi.org/10.5281/zenodo.3686061)
1. Click on "add new version"
1. For a new version, upload the new PDF, naming it consistently with the other
PDFs: `BIDS-Specification-vX.X.X.pdf` (replace `X.X.X` with the new version)
1. Remove all other files from the upload
1. Edit the following fields:
1. publication date
1. version
1. Double check that everything is in order, then save and publish

### 11. Sharing news of the release

Please share news of the release on the [identified platforms](https://docs.google.com/spreadsheets/d/16SAGK3zG93WM2EWuoZDcRIC7ygPc5b7PDNGpFyC3obA/edit#gid=0).
Please use our previous release posts as a guide.