chore(web-forms#821): adds template with release steps#2019
chore(web-forms#821): adds template with release steps#2019latin-panda wants to merge 5 commits into
Conversation
latin-panda
changed the title
| - [ ] Run `npm run changeset version` in `central-frontend`. This consumes the `.changeset/` files, bumps package versions, and updates each `CHANGELOG.md`. | ||
| - [ ] Commit the changes on a new branch (e.g., `release-version-bumps`) and open a PR targeting `master`. |
There was a problem hiding this comment.
We are thinking of automating this piece with GitHub Actions (previous conversation). When the release tag is pushed, it generates the changelogs and creates a PR.
|
I'm focused on other work at the moment, but I don't want to block things here. I went ahead and tagged @lognaturel and @garethbowen in case one of them has time to take a look. The most important thing from my perspective is that the new template matches the existing Google doc. |
There was a problem hiding this comment.
Is this an officially recognised GH template? I can't find any information about it.
In the past I have used issue templates for release checklists, so you can create a new instance by creating an issue. Is that possible with this format or is there another process to follow?
There was a problem hiding this comment.
It's an issue type. I got confused when I saw the ISSUE_TEMPLATE.md and put it there, same as that template, without a header. It's fixed
There was a problem hiding this comment.
Actually, the ISSUE_TEMPLATE.md isn't working. I've asked the QA team, and they agreed to add it back. I've done that and named it QA create issue to make it clearly distinct from the other bug-report templates that redirect to the forum.
| > - 🚀 Major release only | ||
| > - 🛠 Patch release only | ||
| > - 🔎 Requires the second person (reviewer) | ||
| > - Unmarked steps apply to **both** major and patch releases. |
There was a problem hiding this comment.
There are quite a few steps that are one or the other, so it might make sense to create two templates, one for Major and one for Patch. This is doable with issue templates but I don't know how release templates work.
There was a problem hiding this comment.
I agree, I was thinking the exact same thing. I decided to hold off on splitting them just yet to make the initial move from Google Docs smoother and easier for everyone and simplify the review. Once we transition the current process over successfully, splitting them into Major/Patch templates will be a natural next step.
Does that approach make sense, or do you think the friction of having two templates right away would be pretty minimal?
| * [apps/central](link-to-CHANGELOG#version) | ||
| * [apps/forms](link-to-CHANGELOG#version) | ||
| * [packages/web-forms](link-to-CHANGELOG#version) | ||
| * [packages/xforms-engine](link-to-CHANGELOG#version) | ||
| * [packages/xpath](link-to-CHANGELOG#version) |
There was a problem hiding this comment.
We can hardcode the links before the # right?
There was a problem hiding this comment.
Yes, I considered that. However, I'm concerned that if we use the format
https://github.com/getodk/central-frontend/blob/master/packages/web-forms/CHANGELOG.md#<version>
developers might just type the version as 1.3.0. That won't scroll to the correct section because the anchor link requires the version number without dots (e.g., 130).
To avoid this issue, I thought it would be best to leave it as is so they can just copy and paste it directly.
There was a problem hiding this comment.
I've added a comment and made the link explicit to add the version correctly. We'll see if it works well :)
garethbowen
left a comment
garethbowen
left a comment
There was a problem hiding this comment.
Minor suggestions. Otherwise, looking good!
|
@matthew-white, this has been approved, but let me know if you'd still like to take a look before merging |
lognaturel
left a comment
lognaturel
left a comment
There was a problem hiding this comment.
I agree that @matthew-white should take a look! For my part, I really like that this makes the release checklist versioned and I think it will be helpful to have a persistent place to check things off and communicate notes about anything that comes up.
4 participants
Closes getodk/web-forms#821
What has been done to verify that this works as intended?
Compared with the Google Docs that has the steps
Why is this the best possible solution? Were any other approaches considered?
Release steps are versioned and can be improved by opening a PR.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
no
Does this change require updates to documentation? If so, please file an issue here and include the link below.
no
Before submitting this PR, please make sure you have:
nextbranch OR only changed documentation/infrastructure (masteris stable and used in production)