How should we support "make upgrade" on a release branch?
As packages change out in the world, new pins get added to master, like this one: https://github.com/edx/edx-platform/pull/27959
If we don't bring those pins over to the release branch, then "make upgrade" won't work on the release branch. But "make upgrade" is dangerous on the release branch in the first place, because we don't have a way to validate the updated packages.
This came up because a developer asked in Slack how to get their new django app into the installation. The answer is to add it to "base.in" and then run "make upgrade", but that leads to these sort of problems.
What should we do?
The answer is to add it to "base.in" and then run "make upgrade", but that leads to these sort of problems.
The answer is actually to run make compile-requirements, which re-compile *.txt files but does not upgrade pinned requirements. I think this resolves the problem, right?
That's our solution for edx-platform, although we don't consistently support it in other repos yet: https://github.com/edx/edx-platform/tree/master/requirements#upgradingdowngrading-just-one-dependency . Should this be added to OEP-18?
@nedbat can we close this?
So far we have four comments in the discussion, and they all end with a question mark. Someone needs to determine the right answer and record it someplace.