Description
OEP-10 pins a repository into a release by cutting a release/RELEASENAME branch and tagging it, which works for components that are deployed from, or built out of, a checkout of themselves. Under OEP-65 a frontend app is neither, so a release branch in an app repository would be inert: nothing deploys from it and nothing consumes it. Nothing in openedx-proposals currently says how such a repository participates in a release instead.
OEP-10 itself changes to distinguish components that a release pins by git reference from those it pins by published version, saying where the record of a pinned version lives and that being pinned by version does not lower a component's obligations under levels of support. None of that is frontend-specific; Python libraries pinned in edx-platform's requirements files work the same way.
Three ADRs follow. OEP-10 ADR 0002, moved here from frontend-base ADR 0012, settles what branches a semantically-released frontend repository has, what each of them publishes, how changes travel between them, and how stable moves onto a new major. OEP-10 ADR 0003 settles how such a repository takes part in an Open edX release, by published version rather than by a branch cut at release time. OEP-65 ADR 0004 settles how an app repository's frontend-base conversion branch takes over as its main branch, that the OEP-10 ADRs govern its branches from that point on, and where the micro-frontend it replaces continues to live.
Part of #560.
Implemented by openedx/openedx-proposals#815
Description
OEP-10 pins a repository into a release by cutting a
release/RELEASENAMEbranch and tagging it, which works for components that are deployed from, or built out of, a checkout of themselves. Under OEP-65 a frontend app is neither, so a release branch in an app repository would be inert: nothing deploys from it and nothing consumes it. Nothing inopenedx-proposalscurrently says how such a repository participates in a release instead.OEP-10 itself changes to distinguish components that a release pins by git reference from those it pins by published version, saying where the record of a pinned version lives and that being pinned by version does not lower a component's obligations under levels of support. None of that is frontend-specific; Python libraries pinned in
edx-platform's requirements files work the same way.Three ADRs follow. OEP-10 ADR 0002, moved here from
frontend-baseADR 0012, settles what branches a semantically-released frontend repository has, what each of them publishes, how changes travel between them, and howstablemoves onto a new major. OEP-10 ADR 0003 settles how such a repository takes part in an Open edX release, by published version rather than by a branch cut at release time. OEP-65 ADR 0004 settles how an app repository'sfrontend-baseconversion branch takes over as its main branch, that the OEP-10 ADRs govern its branches from that point on, and where the micro-frontend it replaces continues to live.Part of #560.
Implemented by openedx/openedx-proposals#815