docs: Add frontend branching strategy ADR#94
Conversation
arbrandes
force-pushed
the
main
branch
3 times, most recently
from
a6124e6 to
7e13eb9
Compare
arbrandes
force-pushed
the
frontend-branching-strategy-adr
branch
2 times, most recently
from
b9c5038 to
bf84e2f
Compare
| ----------------------------------- | ||
|
|
||
| A repository's main branch will be published semantically to NPM with on an | ||
| "alpha" prerelease tag, with a monotonically incremented version number. For |
There was a problem hiding this comment.
I'm not married to "alpha". It could be "main", or "next", or anything else, really (as long as every frontend app repo follows the same pattern, of course).
arbrandes
force-pushed
the
frontend-branching-strategy-adr
branch
from
bf84e2f to
3ea2cbb
Compare
|
So just to be sure I get this right @arbrandes
Now, how or were are we going to track what's compatible with which edx-platform version? |
That's exactly what I'm proposing, yes. (In addition to publishing from main using a prerelease tag such as the one we have now.)
Good question. It begins with this ADR. Prior to each release we'll announce which versions of things will work with that release. So the announcement would be the source of truth. One potential de facto source of truth could be frontend-template-site. Whatever is in its package.json is what that release expects. (We would be tagging frontend-template-site with And obviously Tutor itself, while downstream, would be de facto documentation. |
| Notably, though, the main branch retains the following properties: | ||
|
|
||
| 1. New features should be developed for and merge to it before any other | ||
| branches; | ||
| 2. To facilitate collaboration, the branch is never rebased. |
There was a problem hiding this comment.
I like this, but it'd be good to include a "how we handle bug fixes" part. In Paragon's README we have the Contributing section which includes
The branch to target with your PR depends on the type of change you are contributing to Paragon.
Branch to Target Type of Change Documentation Site release-22.xBug fix/security patch https://paragon-openedx-v22.netlify.app/ release-23.xBug fix/security patch/new (non-breaking) feature https://paragon-openedx-v23.netlify.app/ nextBreaking change https://paragon-openedx.netlify.app/
which can be simplified to
| Branch to Target | Type of Change |
|---|---|
| previous release | Bug fixes/security patches only |
| current release | Bug fixes/security patches/new (non-breaking) features |
| next | Breaking changes |
which doesn't quite match the strategy here. My understanding is that the strategy here is instead
| Desired Branch for feature/fix | Type of Change | Where to target PR |
|---|---|---|
| previous release | Bug fixes/security patches only | main first, backport after? open 2 PRs? |
| current release | Bug fixes/security patches/new (non-breaking) features | main first, backport after? 2 PRs? |
| main | Bug fixes/security patches/new (non-breaking) features/breaking changes | main |
It'd be nice to add a little clarify to that flow that accounts for scenarios such as "we need to get this non-breaking feature into the version that's going out with the release that's being cut next week," or "this is a critical fix that needs to get out to people using a published version ASAP"
There was a problem hiding this comment.
Good call. I added a section with (what I hope is) plenty of clarifying detail.
arbrandes
force-pushed
the
frontend-branching-strategy-adr
branch
2 times, most recently
from
d259908 to
01f2cb5
Compare
arbrandes
force-pushed
the
frontend-branching-strategy-adr
branch
from
01f2cb5 to
bb124a3
Compare
3 participants
This ADR introduces the concept of "main is unstable" to frontend repositories, from whence alpha packages will be published semantically to NPM.
Parent issue: #96