Closed regisb closed 6 months ago
There are repos with branches named "release":
---- ./openedx/edx-analytics-configuration ----
remotes/origin/release
---- ./openedx/edx-analytics-data-api ----
remotes/origin/release
---- ./openedx/edx-analytics-dashboard ----
remotes/origin/release
---- ./openedx/edx-analytics-exporter ----
remotes/origin/release
---- ./openedx/edx-ora2 ----
remotes/origin/release
---- ./openedx/edx-analytics-pipeline ----
remotes/origin/release
---- ./openedx/cs_comments_service ----
remotes/origin/release
---- ./openedx/edx-search ----
remotes/origin/release
The way git uses directories to store branch information, you can't have both a "release" branch and a "release/palm" branch. If you try, you get an error:
fatal: cannot lock ref 'refs/heads/release/palm': 'refs/heads/release' exists; cannot create 'refs/heads/release/palm'
We'll need to update the eight repos to rename their branches and associated workflows/processes.
What about having it prefiex with open/x
instead of release/x
assuming that would resolve the raised conflict and also wouldn't be more meaningful?
What about having it prefiex with open/x instead of release/x assuming that would resolve the raised conflict and also wouldn't be more meaningful?
I think that "open/*" is less meaningful than "release/*". Everything that we are doing is supposed to be open, so that "open" prefix does not really make sense.
The "release" branches in the repo mentioned by Ned above are confusing, and we should get rid of them:
https://github.com/openedx/edx-analytics-configuration/tree/release https://github.com/openedx/edx-analytics-data-api/tree/release https://github.com/openedx/edx-analytics-dashboard/tree/release https://github.com/openedx/edx-analytics-exporter/tree/release https://github.com/openedx/edx-ora2/tree/release https://github.com/openedx/edx-analytics-pipeline/tree/release https://github.com/openedx/cs_comments_service/tree/release https://github.com/openedx/edx-search/tree/release
Of these branches, only the edx-analytics-pipeline seems to be actively maintained. I think it's OK if we make an exception and do not create a branch for this repo in Palm -- at least not right away. Let's ask one of the maintainers: @HassanJaveed84, as one of the last committers, can I please get your attention on this issue? Would it be possible to rename the "release" branch of the edx-analytics-pipeline repo?
This is tangential, but since we're about to change how we name branches & tags, it would be a good time to think about how we release tags too: https://openedx.slack.com/archives/C049JQZFR5E/p1681224120187389. It could be helpful to the community if we make all the changes at the same time.
@regisb @kdmccormick should this still be a priority for Palm?
No, postponed to Quince. We realized that there was indeed trouble to change the name, because there already exists a "release" branch in some of the Open edX repos.
Just something I forgot to mention earlier, we also need to check for tags because git/github treats branch and the tag same in some cases. i.e. in git for checkout and for github in the url
@timmc-edx did some work moving branches: https://github.com/edx/open-source-process-wg/issues/94
No one was in charge of this issue, so I'm not sure whether we'll be able to make the change for Quince... Unless someone deletes the "release" branches in the repos listed above?
I'll make sure that the conflicting branches are gone before Redwood. Once that's done, if someone else is able to take on the task of updating the docs and the release script, I'd appreciate it.
@regisb @cmltaWt0
The bad news: There are still a few repos left with release
branches, which I did not manage to get cleared for deletion, so we will need to use open-release/...
prefix again for Redwood. My bad.
The good news: The remaining release
branches are all in deprecated repos, and those repos will be archived right after the Redwood cut! They are:
So, for Sumac, BTR is all clear to switch the branch prefix to release/
if they wish to.
Here's how I listed the (you need to install ghapi
and set the GITHUB_TOKEN
env var to run this):
#!/usr/bin/env bash
{
for repo in $(gh api --paginate /orgs/openedx/repos --jq '.[].name' | grep -v '\-ghsa-' | sort) ; do
echo $repo
for branch in $(gh api --paginate /repos/openedx/$repo/branches --jq '.[].name' | grep -E '^release(/.*)?$') ; do
echo " ~ $branch"
done
for tag in $(gh api --paginate /repos/openedx/$repo/tags --jq '.[].name' | grep -E '^release(/.*)/?$') ; do
echo " @ $tag"
done
done
} | tee openedx-release-conflict-branches.txt
As of 2024-04-30, with the old analytics repos archived, no openedx repos have release
as a branch or tag.
A few repos have tags under the release/
namespace, but none of them should conflict with the named releases:
xblock-free-text-response
@ release/v2.1.0
@ release/v1.1.1
@ release/v1.0.1
@ release/v1.0.0
@ release/v0.4.0
@ release/v0.3.1
@ release/v0.3.0
@ release/v0.2.0
@ release/v0.1.9
@ release/v0.1.8
@ release/v0.1.7
@ release/v0.1.6
@ release/v0.1.5
@ release/v0.1.4
@ release/v0.1.3
xblock-in-video-quiz
@ release/v0.1.8
@ release/v0.1.7
@ release/v0.1.6
@ release/v0.1.5
@ release/v0.1.4
@ release/v0.1.3
@ release/v0.1.2
@ release/v0.1.1
@ release/v0.1.0
xblock-qualtrics-survey
@ release/v1.1.0
@ release/v0.1.3
@ release/v0.1.2
@ release/v0.1.1
xblock-sql-grader
@ release/v/0.2.0
xblock-submit-and-compare
@ release/1.1.0
@ release/0.7.0
@ release/0.6.2
@ release/0.5.2
Finally, only one repo has a branch under the release/*
namespace: the repo openedx-i18n, with the branch release/quince
. That repo is not marked for tagging, so we don't need to worry about (in fact, I think we can archive this repo but that's not important here).
So, BTR, at long last you are finally clear to take over the release/*
namespace!
There was a widespread community agreement that we should switch to a different pattern for naming release branches and tags:
This conversation was held here: https://discuss.openedx.org/t/should-we-rename-the-release-branches/8827 @e0d wrote an ADR here: https://github.com/openedx/.github/pull/36 That ADR is approved but was not merged yet.
We should check whether the "release/*" pattern will interfere with any existing branch that follows that same pattern. This potential issue was raised by @kdmccormick in this Slack conversation: https://app.slack.com/client/T02SNA1T6/threads/thread/C02SNA1U4-1680624333.853709