Change main branch from "master" to "main"

[willschlitzer]

In the interest of inclusivity, should we change the main git branch from master to main? This would be in line with changes to large Python repos, including CPython, Numpy, Flask, and Django, as well as the default main branch for all new GitHub repos.

Are you willing to help implement and maintain this feature? Yes

[seisman]

I'm OK with the change.

[michaelgrund]

Mee, too! Are there any technical issues which could come up when changing the master branch?

[core-man]

Mee, too! Are there any technical issues which could come up when changing the master branch?

I don't think so from my experience for this change 😄

[weiji14]

Guidance is at https://github.com/github/renaming. Contributors will need to point their git remote to the new 'main' branch locally on their computers, and there will need to be a Pull Request to rename 'master' to 'main' across our documentation/CI scripts/etc.

[maxrjones]

I support the change. Seems that github has made the process rather streamlined.

[willschlitzer]

Guidance is at https://github.com/github/renaming. Contributors will need to point their git remote to the new 'main' branch locally on their computers, and there will need to be a Pull Request to rename 'master' to 'main' across our documentation/CI scripts/etc.

I don't have the rights to rename the default branch, but I have submitted a draft PR changing documentation and CI scripts.

[maxrjones]

At the same time, we could update the 'master' CPT references in the docstrings for these two functions:

./pygmt/src/grd2cpt.py
./pygmt/src/makecpt.py

[seisman]

At the same time, we could update the 'master' CPT references in the docstrings for these two functions:

./pygmt/src/grd2cpt.py
./pygmt/src/makecpt.py

But they are called "master" CPT in GMT.

[seisman]

One more note: there are some links in the old documentation that are linked to files on the master branch, for examples, links to the LICENSE.txt, CONTRIBUTING.md and links to example source files. Changing "master" to "main" also breaks the old documentation (including the latest v0.4.0 documentation).

Does GitHub automatically redirect any links of master branch to "main"? If not, do we want to update the old documentation in the gh-pages?

[willschlitzer]

One more note: there are some links in the old documentation that are linked to files on the master branch, for examples, links to the LICENSE.txt, CONTRIBUTING.md and links to example source files. Changing "master" to "main" also breaks the old documentation (including the latest v0.4.0 documentation).

Does GitHub automatically redirect any links of master branch to "main"? If not, do we want to update the old documentation in the gh-pages?

While I don't want to limit anyone's access to information, do we expect many individuals to be clicking through our old documentation? On that topic, is there typically an expectation to support old documentation versions once new versions are released?

[maxrjones]

One more note: there are some links in the old documentation that are linked to files on the master branch, for examples, links to the LICENSE.txt, CONTRIBUTING.md and links to example source files. Changing "master" to "main" also breaks the old documentation (including the latest v0.4.0 documentation).

Does GitHub automatically redirect any links of master branch to "main"? If not, do we want to update the old documentation in the gh-pages?

My understanding is that the redirection will not be a problem: https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/. What do you mean by it breaks the old documentation?

[seisman]

While I don't want to limit anyone's access to information, do we expect many individuals to be clicking through our old documentation? On that topic, is there typically an expectation to support old documentation versions once new versions are released?

I don't think we should take the time to fix old documentation. However, we have to make sure that links in the v0.4.0 documentation don't break, because v0.4.0 is the latest stable version.

My understanding is that the redirection will not be a problem: github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch. What do you mean by it breaks the old documentation?

The page says:

This change only affects view links; other types of links (like edit links and blame links) don't redirect.

I think it means that the "Improve the page" links at the top right corner of each gallery/tutorial won't work.

[weiji14]

While I don't want to limit anyone's access to information, do we expect many individuals to be clicking through our old documentation? On that topic, is there typically an expectation to support old documentation versions once new versions are released?

I don't think we should take the time to fix old documentation. However, we have to make sure that links in the v0.4.0 documentation don't break, because v0.4.0 is the latest stable version.

My understanding is that the redirection will not be a problem: github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch. What do you mean by it breaks the old documentation?

The page says:

This change only affects view links; other types of links (like edit links and blame links) don't redirect.

I think it means that the "Improve the page" links at the top right corner of each gallery/tutorial won't work.

Right, so you mean a link like https://github.com/GenericMappingTools/pygmt/edit/master/doc/index.rst will be broken as it won't redirect to https://github.com/GenericMappingTools/pygmt/edit/main/doc/index.rst? We could find-and-replace master to main all the links at https://github.com/GenericMappingTools/pygmt/tree/gh-pages/v0.4.0. OR, we should just get a v0.4.1 release out after merging in #1360 and have everything point to 'main' instead of 'master'.

[willschlitzer]

So are we holding off on completing this change until release v0.4.1, and if so, when should that be?

[weiji14]

So are we holding off on completing this change until release v0.4.1, and if so, when should that be?

Maybe a good idea to wait until after the SciPy sprints on 17/18 July so that the edit links don't break. But do it before the ESWN developer workshop on 17-19 Aug. Sometime late July 2021 perhaps for PyGMT v0.4.1?

[willschlitzer]

So are we holding off on completing this change until release v0.4.1, and if so, when should that be?

Maybe a good idea to wait until after the SciPy sprints on 17/18 July so that the edit links don't break. But do it before the ESWN developer workshop on 17-19 Aug. Sometime late July 2021 perhaps for PyGMT v0.4.1?

I think it's smart to hold off waiting for higher-profile events like the SciPy sprints to make sure we don't break anything in the change, but couldn't we potentially expect some major features to be added in the sprints/developers workshop, making it seem more like the release of v0.5.0 than v0.4.1?

[weiji14]

So are we holding off on completing this change until release v0.4.1, and if so, when should that be?

Maybe a good idea to wait until after the SciPy sprints on 17/18 July so that the edit links don't break. But do it before the ESWN developer workshop on 17-19 Aug. Sometime late July 2021 perhaps for PyGMT v0.4.1?

I think it's smart to hold off waiting for higher-profile events like the SciPy sprints to make sure we don't break anything in the change, but couldn't we potentially expect some major features to be added in the sprints/developers workshop, making it seem more like the release of v0.5.0 than v0.4.1?

Yep you're right, it may well be v0.5.0 actually. Won't stop a good feature from landing during the sprint! Will decide when the time comes though.

[weiji14]

Maybe a good idea to wait until after the SciPy sprints on 17/18 July so that the edit links don't break. But do it before the ESWN developer workshop on 17-19 Aug. Sometime late July 2021 perhaps for PyGMT v0.4.1?

I think it's smart to hold off waiting for higher-profile events like the SciPy sprints to make sure we don't break anything in the change, but couldn't we potentially expect some major features to be added in the sprints/developers workshop, making it seem more like the release of v0.5.0 than v0.4.1?

Yep you're right, it may well be v0.5.0 actually. Won't stop a good feature from landing during the sprint! Will decide when the time comes though.

There hasn't been any feature PRs added for SciPy2021, so do we want to go with a bugfix PyGMT v0.4.1 release by end of July/early Aug? That way we can get the renaming PR at #1360 done before the ESWN workshop.

[willschlitzer]

There hasn't been any feature PRs added for SciPy2021, so do we want to go with a bugfix PyGMT v0.4.1 release by end of July/early Aug? That way we can get the renaming PR at #1360 done before the ESWN workshop.

I think that makes sense; do we have many other minor changes that we're waiting on before v0.4.1 can be released? Also, will switching from master to main cause many merge conflicts in existing PRs, or should it be a pretty seamless update?

[maxrjones]

The motivation for v0.4.1 rather than v0.5.0 which would allow merging in an approved new feature (#1380) isn't clear to me. Can someone explain?

[weiji14]

There hasn't been any feature PRs added for SciPy2021, so do we want to go with a bugfix PyGMT v0.4.1 release by end of July/early Aug? That way we can get the renaming PR at #1360 done before the ESWN workshop.

I think that makes sense; do we have many other minor changes that we're waiting on before v0.4.1 can be released? Also, will switching from master to main cause many merge conflicts in existing PRs, or should it be a pretty seamless update?

Once we merge in the documentation PRs, it should be ok to start on the v0.4.1 release. Switching from master to main will retarget all existing PRs to main, so yes, should be relatively seamless.

The motivation for v0.4.1 rather than v0.5.0 which would allow merging in an approved new feature (#1380) isn't clear to me. Can someone explain?

I meant doing v0.4.1 first, and then merging the feature at #1380 (which will be available for v0.5.0).

Just checking though, is it ok to merge in an 'enhancement' PR (e.g. the pathlib support one) for v0.4.1? Or would that push things to v0.5.0? Felt like this was discussed somewhere before.

[willschlitzer]

The motivation for v0.4.1 rather than v0.5.0 which would allow merging in an approved new feature (#1380) isn't clear to me. Can someone explain?

I meant doing v0.4.1 first, and then merging the feature at #1380 (which will be available for v0.5.0).

My thought is that the debate over v0.4.1 vs. v0.5.0 is centered on if there are any additions we want in the latest release as soon as possible (to include switching master to main) instead of a few months from now. I don't think there have been enough changes in the month since v0.4.0 was released to merit v0.5.0 getting released soon (I assume it would be September-November time frame based upon the 4-5 months for the last few releases). If we're fine with these features not being in the latest release until then, I see no reason to have a v0.4.1.

My vote is to still have a v0.4.1 released in the next few months. I think changing the branch to main is an important step, and it never hurts to release more up-to-date documentation.

Just checking though, is it ok to merge in an 'enhancement' PR (e.g. the pathlib support one) for v0.4.1? Or would that push things to v0.5.0? Felt like this was discussed somewhere before.

If I remember correctly, there was a comment from late 2020 that stated that v0.2.1 should have been v0.3.0 based on the new wrapped modules. I don't think an enhancement PR like pathlib, while a good addition, is significant enough to rule out v0.4.1.

[seisman]

Just checking though, is it ok to merge in an 'enhancement' PR (e.g. the pathlib support one) for v0.4.1? Or would that push things to v0.5.0? Felt like this was discussed somewhere before.

We had some discussions in #945 (comment).

The motivation for v0.4.1 rather than v0.5.0 which would allow merging in an approved new feature (#1380) isn't clear to me. Can someone explain?

Also please note that we will remove some deprecated parameters (e.g., sizes vs size in plot, plot3d) in PyGMT v0.6.0, assuming that we make a new release every ~3 months.

Releasing v0.5.0 in late July or early August means that v0.6.0 will be ~2 months earlier than planned, which give less time for users to see the deprecation warnings and make changes.

[maxrjones]

Releasing v0.4.1 within the few weeks and sticking to the regular schedule for v0.5.0 sounds good to me.

[weiji14]

Releasing v0.4.1 within the few weeks and sticking to the regular schedule for v0.5.0 sounds good to me.

Alright, we'll need to assign a release manager. Do you want to do it again @meghanrjones? Or we can choose someone who hasn't done it before like @michaelgrund or @core-man if they are keen to try. This is a pretty small release so shouldn't be too difficult 🤞

[core-man]

Releasing v0.4.1 within the few weeks and sticking to the regular schedule for v0.5.0 sounds good to me.

Alright, we'll need to assign a release manager. Do you want to do it again @meghanrjones? Or we can choose someone who hasn't done it before like @michaelgrund or @core-man if they are keen to try. This is a pretty small release so shouldn't be too difficult

😄 I'd like to do the release v0.4.1 if either meghanrjones or michaelgrund is not available then.

[willschlitzer]

This is a pretty small release so shouldn't be too difficult 🤞

Famous last words! 😝

[maxrjones]

Releasing v0.4.1 within the few weeks and sticking to the regular schedule for v0.5.0 sounds good to me.

Alright, we'll need to assign a release manager. Do you want to do it again @meghanrjones? Or we can choose someone who hasn't done it before like @michaelgrund or @core-man if they are keen to try. This is a pretty small release so shouldn't be too difficult

😄 I'd like to do the release v0.4.1 if either meghanrjones or michaelgrund is not available then.

Great, thanks for volunteering!

[michaelgrund]

Releasing v0.4.1 within the few weeks and sticking to the regular schedule for v0.5.0 sounds good to me.

Alright, we'll need to assign a release manager. Do you want to do it again @meghanrjones? Or we can choose someone who hasn't done it before like @michaelgrund or @core-man if they are keen to try. This is a pretty small release so shouldn't be too difficult

😄 I'd like to do the release v0.4.1 if either meghanrjones or michaelgrund is not available then.

Thanks @core-man for doing it 😉.

[seisman]

Maybe a good idea to wait until after the SciPy sprints on 17/18 July so that the edit links don't break. But do it before the ESWN developer workshop on 17-19 Aug. Sometime late July 2021 perhaps for PyGMT v0.4.1?

What about releasing v0.4.1 on Aug. 7? It's the weekend after the AGU abstract submission deadline, and 10 days before the ESWN developer workshop.

[seisman]

@core-man Please make an issue to track the v0.4.1 release. See #1333 for an example issue for v0.4.0.

[maxrjones]

I renamed the branch from master to main. GitHub says that all the PR targets will be updated but contributors will need to update their local environment. Here are the commands provided:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

[maxrjones]

@weiji14, do you know how to update the default branch on DAGsHub?

[weiji14]

@weiji14, do you know how to update the default branch on DAGsHub?

Why? The DAGsHub repo is just a mirror of the GitHub repo. I think the master branch should have disappeared already.

[maxrjones]

@weiji14, do you know how to update the default branch on DAGsHub?

Why? The DAGsHub repo is just a mirror of the GitHub repo. I think the master branch should have disappeared already.

I was wondering because the default branch is listed as add_hotspot_data now that the master branch is gone (https://dagshub.com/GenericMappingTools/pygmt/branches), but it's not a big deal.

[weiji14]

@weiji14, do you know how to update the default branch on DAGsHub?

Why? The DAGsHub repo is just a mirror of the GitHub repo. I think the master branch should have disappeared already.

I was wondering because the default branch is listed as add_hotspot_data now that the master branch is gone (https://dagshub.com/GenericMappingTools/pygmt/branches), but it's not a big deal.

Ah I see. I didn't see any setting for that, so maybe raise it with DAGsHub, if you can find their issue tracker.