-
Notifications
You must be signed in to change notification settings - Fork 32
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
Use catalog-info.yaml for release metadata. Get rid of openedx.yaml #526
Conversation
Details about why are in ADR-4 of OEP-55 which is in a follow-on commit.
Track release information in the `catalog-info.yaml` file instead of in the `openedx.yaml` file. This will supersede the decision made in OEP-2.
581f75b
to
298ea3f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One missing word, then merge it!
oeps/processes/oep-0055/decisions/0004-release-data-in-catalog-info-files.rst
Outdated
Show resolved
Hide resolved
…atalog-info-files.rst Co-authored-by: Ned Batchelder <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good to me!
I'm realizing now (while watching the Quince cut) that we no longer have a way to say "maybe." What will our approach be? With openedx.yaml, the cookiecutter started the file off with maybe:true as a way to alert the release manager that no decision had been recorded. Do we want to use the complete absence of the key to mean that? |
@kdmccormick I think nothing needs to change on the BTR side, once openedx/repo-tools#467 lands, it should to work automatically. |
Ah, I wasn't aware of that PR. Cool, thanks. |
OEP-55:ADR-4 in this PR has most of the context of what I'm proposing so I suggest reading that first. The rest is just a consequence of that decision.