TEP: Rename nightly->main and master->release

Background

New changes to Open edX repos go on their default branch, named master or main (I’ll just say “main”). Every 6 months we cut an open-release/<TREE>.master branch for the <TREE> release. Only fixes and minor improvements are merged to the open-release branch.

(Note: starting in Sumac, it looks like we’ll shorten the release branch name to to just release/<TREE>.)

Tutor and its plugins also generally have master as their default branch, but this branch does not work with Open edX main. It works with the latest open-release branch of Open edX. The branch that works with Open edX main is called nightly. Tutor devs merge changes to master if they work with the last release, or nightly if they only work with Open edX main.

To recap:

Tutor branch Compatible Open edX branch
nightly main [default]
master [default] open-release/LATEST.master

Proposal

It’s a complex that the default branch for Tutor works with the non-default branch of Open edX, but I think it’s actually a reasonable reflection of the fact that Tutor operates as a distribution/config layer on top of Open edX. So I don’t think that’s the problem.

The problem is that Tutor master and Open edX master don’t match. It’s head-explodingly confusing :exploding_head: , and it totally fails the Principle of Least Surprise.

Here’s what I propose:

Tutor branch Compatible Open edX branch
nightly main main [default]
master release [default] release/LATEST

In addition to renaming the branch, we could rename “Tutor Nightly” offering (which Open edX developers use) to “Tutor Mainline”.

I propose we make these changes as part of Sumac, to coincide with the fact that Open edX release branch names will probably also change.

Thoughts?

2 Likes

Does this mean that we should target our contributions to the new default branch (old nightly) for Tutor and plugins?

Because tutor is relatively quick in merging changes, you can expect your contributions to be merged during the current Open edX release, avoiding the need to use a long lived fork of Tutor. How would the backport strategy look in this new model?

@MoisesGonzalezS I am not proposing any changes to the branching model, just the branch names.

As we do now, you would target most Tutor contributions to release (formerly master), and immediately forward-port them to main (formerly nightly).

Edly, correct me if I’m wrong, but for Tutor itself and probably some of the official plugins this is done automatically every so often via a “merge master into nightly” commit.

I would also go as far as suggesting that the merging strategy for Tutor should also be changed so that all new features go to “mainline” first, then are subsequently backported into “release” (sometimes called the “master is unstable” strategy), something which would further mitigate the disconnect with Open edX repos. But don’t let this derail the original renaming proposal, which is good on its own.

I like the branch proposal and I agree that “Nightly” may not be the best name, but “Mainline” seems worse than “Nightly” to me. Without context, I would assume that mainline refers to the releases, or something, which is the “main” way that most people use tutor / open edx. Whereas “nightly” has a clear definition in software development of auto-generated daily releases that contain the very latest code. That isn’t exactly what Tutor Nightly is (after all, you still build it the images and the frequency is whatever you want), but at least it implies “latest, less stable, frequently changing dev version” so I find it closer than “Mainline”.

I would suggest “Tutor Next” or “Tutor Edge” or just stick with Nightly.

2 Likes

Fair enough w.r.t. “Mainline”, but my gripe with “Nightly” is that it’s literally false and I’ve seen that confuse several people.

Next and Edge both sound great to me :+1:

For what it’s worth, “Tutor Edge” was @regis 's first name for Nightly, but there was some concern about it being confused with https://edge.edx.org, 2U’s other Open edX deployment. I don’t think that would actually have caused any confusion, so I have no opposition to Tutor Edge. Although, if it matters to anyone, we probably cannot ever officially call anything “Open edX Edge” for this reason.

2 Likes

Your concern about the Open edX & Tutor branch naming mismatch is valid. I’ve also seen contributors being confused. Myself, I feel a little silly when I explain that changes pushed to “master” are for the “open-release/*” branches, and changes pushed to “nightly” are for the “master” branches.

I do want to keep the “release” branches the git default, though. (in Tutor) Wouldn’t it be confusing if “release” was the default, instead of “main”? As developers, muscle memory tells us to push our changes to “main/master”. Moises’ first comment confirms this.

But I think we can live this that, and that slight discrepancy is less confusing than the nightly/master mismatch.

This argument is also valid. For that reason, I like “next” when the principal branch is “release”. That’s because it makes it very clear that the “next” branch targets the “next release”.

To recap:

Tutor (current) Tutor (future) Open edX (current) Open edX (future)
master release open-release/zebulon.master release/zebulon
nightly next master master

This is correct.

Yes, if you think this is a viable strategy then let’s discuss this separately :slight_smile:

2 Likes

When I wrote the TEP I was on the fence between “next” and “main” as well for this exact reason :slightly_smiling_face: “Tutor Next” also has a nice ring to it.

(release,next) sounds good to me! :rocket:

2 Likes