Rename master branch to main?

[bwbohl]

Background:

• https://github.com/github/renaming
• https://stevenmortimer.com/5-steps-to-change-github-default-branch-from-master-to-main/

[bwbohl]

thanks @musicEnfanthen for bringing this up!

The ODD Meeting 2021-02-25 is wondering though, whether other naming schemes would be preferable, e.g.:

• master --> released

This would actually better reflect our use of the current "master" branch.

@music-encoding/core-contributors any comments?

[musicEnfanthen]

Since this would potentially affect all repos within the MEI, one idea could be to choose a branch name that works for all repos. Absolutely not insisting on main and happy about other proposals, but not quite sure if released works with all scenarios (e.g. the website or schema repo do not quite follow the concept of releases at the moment. And using different branch names in different repos for what used to be master doesn't seem to be a good idea, paves the way for confusion.)

[lpugin]

What about master 😊 ? More seriously, I think we need to take into account the fact that on some repositories (most of them?), master is the default, and in others (at least one) not. So maybe it is not a bad idea to have a different name making this distinction more easily understandable.

• music-encoding/music-encoding
  • develop [default]
  • releases
• music-encoding/guidelines
  • master [default]
  • develop
• music-encoding/music-encoding.github.io
  • master [default]
  • develop

[craigsapp]

main is the most popular replacement for master that we're seeing across GitHub. We like it because it's short, it keeps your muscle memory intact, and it translates well across most languages. We're using main for our newly-created repositories and for the repositories we're moving now, like dependabot-core.

main instead of master is due to political correctness (i.e., master/slave connotation), but given an option, main makes more semantic sense, especially when branch content is not related to other branches (such as gh-pages branch which does not contain the source code found in other branches.

https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main
https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know

Having a repository without master or main is confusing, so what about:

• music-encoding/music-encoding
  ** main [not default, but should contain the most recent stable release]
  ** develop [default]
  ** releases [i.e., a different branch for each release (which can be updated for bug fixes only)]

In other words, it is useful to have a generic branch name for the most recent release for users who want always the most recent stable release, even if it is an updated release. develop is similar but it is the most recent unstable release. If someone has older files, they can use the specific release against which their encodings are based.

[ahankinson]

We already effectively have a release branch, which is the tags; these allow you to check out the tagged branch at any given point in time. The most important question for releases is “which one?” — it doesn’t make sense for you to have a release branch but not know which release! :)

main makes sense as a common, well-understood name, but it’s not really the “main” branch, since it’s the one with the least activity.

Perhaps “stable” (in opposition to “develop”) is a good alternative that also indicates the purpose? It’s the one with the latest stable version. Previous stable versions can be found with the tags.

[bwbohl]

Things get a bit more complicated with our current repo-setup. All development of MEI Specs and MEI Guidelines happen in
music-encoding/music-encoding but the build artefacts are pushed to music-encoding/schema and music-encoding/guidelines respectively. Consequently the two latter do not need anything but one branch (the name of which should probably reflect their purpose). Both repositories hold several parallel versions of their contents, e.g. guidelines v3, v4, dev or schema 3.0.0, 4.0.0, 4.0.1, dev.
So actually neither released nor develop are appropriate, as they hold both at the same time…
A solution could be to name the single one branch there main or continuous-integration or something more adequate?

On music-encoding/music-encoding we need:

• one branch for the general latest development
• depending on our efforts to come up with a more structured release-plan me might could need additional branches for specific release development, e.g. develop-5.0.0 to cherry pick certain developments from their individual PRs to go into specific releases but that's uncertain future,
• when a release is ready it should be merged and tagged, and a release info should be added.

But actually taking @ahankinson seriously we could abandon this double branch model (e.g. develop-released) as every tag (that is created upon release) can be retrieved. So we could rename master to main (preserving all the release tags), merge develop into main and delete it afterwards because we have the guidelines and schema repos with all the build artefacts. The only one thing that would get complicated in this setup is what @craigsapp would like to have with individual release-branches for easier bug fixing. But I don't think we have enough manpower to bugfix older releases (even if we should ;-)). What do you think?

[ahankinson]

But actually taking @ahankinson seriously

Thanks!

So we could rename master to main

It isn't the main branch, when you look at the actual activity on it, where you might look for the current state of the project; develop is where most of the activity happens. But it is the "main" branch when you look at the public face of it. So my concern with main is that it's ambiguous: Is it the "main" activity branch, or the "main" stable you-should-use-this-code branch? We keep saying "main" is where the stable release is; that seems like unnecessary indirection. Just call it what it is. :)

merge develop into main and delete it afterwards because we have the guidelines and schema repos with all the build artefacts

Hm. I get where you're going, but I think keeping the most recent stable version as a branch has some advantages. The biggest advantage is that it gives us a place to merge to, and it also gives us the ability to switch between stable and develop versions without going through an intermediary tag. Otherwise, getting the code at the release tag means first creating it as a new branch, and then switching to that branch. Since it's obvious that we're always going to have a state of the code we're working on, and the most recent state that other people should use, then I think it makes sense to have both active in parallel.

individual release-branches for easier bug fixing

If and when the need arises, it is possible to create a bugfix branch from a tag, and any time we do need a change a release we will almost certainly want to mint a new stable version incrementing the release number with the fix, which means merging the bugfix back into stable and develop, and then likely deleting the branch where the work was done. So individual release branches are effectively dead-ends, holding the state of a repo at a given time -- exactly like what a tag does.

As a general comment, I don't really see any need to make all the repos in the organization uniform -- main or website might be perfectly acceptable in the guidelines and schema repos if they only have one set of branches, while stable and develop (or whatever) could both be used in the core.

[bwbohl]

Agreed upon keeping develop and something reflecting

the "main" stable you-should-use-this-code branch

as you said it's convenient to have it.
Let's give it a name, please take votes:

On music-encoding rename master to:

• stable
• release
• released

On the other repos rename master to:

• main
• stable
• release
• released

[ahankinson]

+1 to 'stable' on music-encoding/music-encoding

+0 to any of the options for the other repos. Any would be fine.

[musicEnfanthen]

I like @ahankinson 's proposal of stable, and would prefer to have the same name for the former "master" branch in all repos. (I see some sources of confusion with multiple names.) So:

+1 to stable

[kepper]

I think stable on music-encoding/music-encoding is the most comprehensive solution. For the other repos, I also have less of an opinion, and would be perfectly fine with main as this seems to be the default people expect when there is no master… 

[kepper]

At the ODD meeting today, we discussed this a bit, and there was no full consensus to use stable. Another option we discussed was latest(or latest-releaseor some such). The other, probably more important aspect is how to actually implement this and notify users of this change. We would like to announce this in advance to the community, so we need to take a decision on the name in the next two weeks or so, and then implement it at the April meeting.

[ahankinson]

It would be good to have the other viewpoints on this ticket for the benefit of those of us who could not make the meeting today, just to get those on record. (and to participate in @bwbohl 's poll!)

As for how to do it, it's pretty straightforward mechanically -- I have done it for a few of my own repos. The hardest part will be to make sure all the CI scripts, etc. have been modified as well.

I am happy to take the lead on doing the change, once the name has been settled.

[musicEnfanthen]

Thank you @ahankinson! There was someone (not giving any names ;) not totally confident with stable, because it could happen that the code base on the now master branch is indeed not stable, but would need a hotfix. That's the context where latest was introduced as another option; latest in the sense of the branch having the latest (stable/main/reliable/release = i.e. non-develop) version of the code. Since we didn't discuss this option before and it wasn't included in the poll above, we decided to postpone the decision to collect more opinions (maybe with a more "official" poll on Slack?).

Yes, you are right, the mechanism is pretty straightforward. But we would need to make sure that all forks are informed and should provide an easy-to-find and easy-to-follow instruction.
The GH action scripts do not directly target the branch in question, so this shouldn't be a problem. However, there are still some other master references in the code base: https://github.com/music-encoding/music-encoding/search?q=master (not all of them relevant to the changes here.)

[lpugin]

it could happen that the code base on the now master branch is indeed not stable, but would need a hotfix.

I am not convinced by this argument. When we make a release, we genuinely believe for it to be stable. If eventually, something is discovered and needs a new release, that's fine. Then we make the release and that one becomes the stable one. This is why we have semantic versioning.

[bwbohl]

Dear MEI Community,

following a suggestion by the Software Freedom Conservancy GitHub renamed their master-branch to main in order to avoid potentially offensive vocabulary or allusions to slavery.

MEI would like to follow this lead and rename the master-branch of https://github.com/music-encoding/music-encoding and other repositories where applicable. Following the discussion on GitHub (#776) the Technical Team set up this poll to take in the community's votes on a closed list of potential new names for our current master-branch, used to disseminate tagged versions (e.g. MEI 3.0.0, MEI 4.0.0 MEI 4.0.1).

Please cast your vote until 2021-04-28 using the form available at:
https://abstimmung.dfn.de/tNOBDWgWAFtVz6lr

This might be of special interest for:
@music-encoding/core-contributors, @music-encoding/tool-developers

and fork owners:
@ahankinson, @annplaksin, @apacha, @aseipelt, @BeethovensWerkstatt, @BruxDDay, @bwbohl, @CarlosUh, @davidrizo, @dinamix, @doerners, @donbyrd, @dotmonkey, @frakel, @fritexvz, @fujinaga, @giulianodibacco, @ironchicken, @ism-dme, @JRegimbal, @kepper, @KristinaRichts, @lpugin, @LVWood, @martha-thomae, @maxweberstiftung, @minamouse, @musicEnfanthen, @Noise-Labs, @o-sapov, @ptuloup, @raffazizzi, @rettinghaus, @riedde, @RubinOrlando, @th-we, @tido, @timothydereuse, @uliska, @vigliensoni, @yrammos, @Yuerong2

[kepper]

feedback of the poll above led to a balance between stable and main, and as the participants of the ODD group in March had a slight preference for stable, we decide to use stable as replacement for masterfrom here on.

[kepper]

@ahankinson, you volunteered to start thinking about the implementation for this, is this offer still standing?

[kepper]

thanks to everyone in the discussion, of course :-)

[ahankinson]

Yes, I can do this. I can do it right now, if that's OK with everyone?

[kepper]

I think we just need to make sure that our workflows don't break over the change, but other than that there's nothing that stops us… thanks!

[musicEnfanthen]

@ahankinson Thanks for the renaming! Worked perfectly.

@bwbohl @kepper Shall we continue with the other repos?

(master branch of all the following repos could be renamed to main, correct?)

• music-encoding (--> stable)

  • adjust wording in generateGuidelines.xsl (--> FROM AN XML TEMPLATE ?)
  • adjust wording in htmlFile.xsl (--> FROM AN XML TEMPLATE ?)

• guidelines (--> main)

  • no own CI workflows
  • also: <!--THIS FILE IS GENERATED FROM AN XML MASTER. DO NOT EDIT!--> in more than 1000 html files, cf. XSLT's mentioned under music-encoding above (--> won't fix)
  • deploy.yml in main repo needs to be adjusted

• schema (--> main)

  • no own CI workflows, nor any mention of master
  • deploy.yml in main repo needs to be adjusted (--> main)

• sample-encodings (--> main)

  • no own CI workflows, nor any mention of master under our control

• encoding-tools (--> main)

  • no own CI workflows, nor any mention of master under our control

• github.io (--> main)

  • remove lines from generateWebsite.xsl in main repo
  • adjust link-checker.yml (--> main)
  • adjust writingTutorials-06.html (--> main)
  • adjust understanding-odd-01.html (--> you'll become proficient in ?)

Request for changes:

• tablature-ig
• neume-ig
• mensural-ig (--> main)
• sibmei (see rename master to main sibmei#169)
• oXygen-MEI-addon (--> stable)

[annplaksin]

@musicEnfanthen Regarding sibmei, we are already discussing the renaming, see music-encoding/sibmei#169

[musicEnfanthen]

@annplaksin Perfect, thanks!

[kepper]

At ODD meeting today, we agreed to follow the list above. However, we need to verify that this won't break our workflows. Maybe @bwbohl, @ahankinson, @musicEnfanthen can have a look together?

[musicEnfanthen]

Updated the list above with necessary steps and cross-repo references

[musicEnfanthen]

Would like to push this forward to have the transition finished this year. @ahankinson would you be able to rename the master branches of the following repos in the next days/weeks (according to the process with the main repo)?

• github.io (--> main)
• sample-encodings (--> main)
• encoding-tools (--> main)
• guidelines (--> main)
• schema (--> main)

[ahankinson]

Yes, I can.

However, for any site that has a published GH page attached to it, it will unpublish the site until another commit is made.

[ahankinson]

[ahankinson]

Done. Please check the respective sites to see if they are still working.

[bwbohl]

• schema is online
• gitHub.io is online
• guidelines is online

[ahankinson]

I have made various changes mentioned in the comment above and have marked them as completed. Ones not checked I did not do.

[musicEnfanthen]

Thank you @ahankinson, that's awesome! Shall we make a short announcement on MEI-L and Slack?

[musicEnfanthen]

I have made various changes mentioned in the comment above and have marked them as completed. Ones not checked I did not do.

Many thanks, the remaining changes are provided in #868