-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change main branch from "master" to "main" #1356
Comments
I'm OK with the change. |
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 😄 |
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 support the change. Seems that github has made the process rather streamlined. |
I don't have the rights to rename the default branch, but I have submitted a draft PR changing documentation and CI scripts. |
At the same time, we could update the 'master' CPT references in the docstrings for these two functions: ./pygmt/src/grd2cpt.py |
But they are called "master" CPT in GMT. |
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? |
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? |
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.
The page says:
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'. |
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. |
There hasn't been any |
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 |
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? |
Once we merge in the documentation PRs, it should be ok to start on the v0.4.1 release. Switching from
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. |
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 My vote is to still have a v0.4.1 released in the next few months. I think changing the branch to
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. |
We had some discussions in #945 (comment).
Also please note that we will remove some deprecated parameters (e.g., 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. |
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. |
Famous last words! 😝 |
Great, thanks for volunteering! |
Thanks @core-man for doing it 😉. |
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. |
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:
|
@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. |
In the interest of inclusivity, should we change the main git branch from
master
tomain
? 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
The text was updated successfully, but these errors were encountered: