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.

Sign up for GitHub

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

doc: update document for major release guide #393

Closed
wants to merge 1 commit into from
Closed

doc: update document for major release guide #393

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
15 changes: 15 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,21 @@ Describe what this pull request changes, and why. Include implications for peopl
- [ ] Consider running your code modifications in the included example app within `frontend-platform`. This can be done by running `npm start` and opening http://localhost:8080.
- [ ] Consider testing your code modifications in another local micro-frontend using local aliases configured via [the `module.config.js` file in `frontend-build`](https://github.com/openedx/frontend-build#local-module-configuration-for-webpack).
- [ ] Verify your commit title/body conforms to the conventional commits format (e.g., `fix`, `feat`) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.
- [ ] Verify intended release version at https://github.com/semantic-release/semantic-release#how-does-it-work

**For Major Release Only**
- [ ] Update dependency/peer dependency repo to support the breaking change
- [ ] https://github.com/openedx/frontend-component-footer
- Example: https://github.com/openedx/frontend-component-footer/pull/241
- [ ] https://github.com/openedx/frontend-component-header
- Example: https://github.com/openedx/frontend-component-header/pull/275
- [ ] https://github.com/edx/frontend-component-footer-edx
- Example: https://github.com/edx/frontend-component-footer-edx/pull/208
- [ ] https://github.com/edx/frontend-component-header-edx
1. [ ] update `@edx/frontend-enterprise-catalog-search`, `@edx/frontend-enterprise-logistration`, `@edx/frontend-enterprise-utils` to use the same peer dependency
- Example: https://github.com/openedx/frontend-enterprise/pull/278
2. [ ] upgrade the release package to `frontend-component-header-edx`
- Example: ....
arbrandes marked this conversation as resolved.
Show resolved Hide resolved
Comment on lines +12 to +24
Copy link
Contributor

Choose a reason for hiding this comment

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

Had a conversation with the tCRIL team yesterday about this, and our position is this:

While tempting, having upstream (this repo) be responsible for downstream (frontend-component-*) is impractical: upstream can never know how many downstream repos there are, ultimately.

We feel the best solution here is for downstream to subscribe to upstream breaking changes instead. This subscription could be theoretically automated via dependabot/renovate or some other bot, which would make the solution even better than a checklist. What do you think?

To be clear, we think the For Major Release Only should be removed. The "Verify intended release version" item is a good check to keep.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is an example of the automation I mentioned above:

openedx-unsupported/frontend-app-ecommerce#217

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That seems a reasonable approach.


**Post merge:**

Expand Down