Jason C. McDonaldNext week, we'll begin the process of renaming the master branch on all our repositories to something else.
In case this movement in tech is a bit unfamiliar to you, or you want to know how to do this yourself, @afrodevgirl has an awesome and succinct summary:
Why the Delay?
We've had this on our plan since mid-June, but we were in the middle of GAME MODE 2020, and given the pace and task prioritization involved, attempting this change then would have been more than a little disruptive to workflow, and quite prone to error.
Now that we're moving into July and back into our usual tasks, the time is right to make the transition.
Renaming the master branch is easy enough itself, but that really belies what's involved:
We have to rename the primary branch on over two dozen repositories.
We have to change the entire CI/CD pipeline to react to changes on the new primary branch name.
We have to update all our standards, policy documents, and workflow documentations to reflect the new primary branch name.
We have to test all of the above.
That really isn't too much to do, but it can easily turn into several days of poking the build system and pipeline with a stick. We don't mind, but hopefully you can see why we had to wait until now!
Picking a Name
We've had a couple of discussions recently as a team about what to call this new branch. After all, if we're changing it anyway, we should take the occasion to find a good name!
Right now, our protected branches look like this:
-
master: the current development version. -
fresh: the current beta or pre-release version. -
stable: the current release version.
Honestly, master never made much sense. We only used it because that was the norm for Git.
We've narrowed the possibilities down to four candidates:
devel
Since the primary branch contains the latest development version, which changes constantly, the name devel might make sense. It sends a clear message to users browsing the repository that this version isn't intended for production use.
devel, fresh, stable. That seems to spell out our workflow pretty well.
edge
Ben Halpern mentioned this name in a comment thread, and I (Jason) rather liked it. It refers to "bleeding edge", which implies that you could use this version of the code, but that you'd need to beware sharp edges and bugs.
edge, fresh, and stable sounds pretty cool, doesn't it?
One downside: this may now also be reminiscent of a certain web browser, which could muddy the issue.
main
This is an option only because GitHub uses it by default. Developers are likely to get used to it, if they aren't already.
The problem is, main seems to have the same vagueness of purpose master did, if not moreso. What would you find in main? The main version? Sounds good to Mr. End User...but they'd be wrong.
Personally, with main, fresh, stable, it makes stable read as stale to me. But maybe that's just my dyslexia talking.
trunk
An oldie but a goodie. This term comes from Subversion, the industry standard version control software before Git really took off. We also get "branch" from this.
Every branch is based on trunk. It just makes sense! But does it fit our workflow? trunk, fresh, stable. Not sure.
What Do You Think?
We're running a poll on our Phabricator instance for all of our contributors to weigh in. You're encouraged to register for an account there via your GitHub (we usually approve new accounts within a couple of hours) and put your two-cents in.
Alternatively, leave a comment here.
Ultimately, the team will make the final call at week's end, so we can start the transition on Monday, 06 July, but we'd love your feedback!
This is not the place to debate about whether master should be renamed. Any comments to that effect will be hidden and reported.
