Consider renaming master branch?

[laniakea64]

The name master for git branches never really made sense to me. And now it is recommended to replace "master" with more technically precise alternatives wherever possible (although that particular link is somewhat political, their FAQ makes clear the initiative is about making terms clearer and more technically precise).

Naming our default branch primary would be way more descriptive of the development flow of this repo.

If we are going to rename the default branch, now would be a good time since the syntax files on master haven't been touched in years and a major update to this project is already in the works anyway.

Obviously this would need to be coordinated with all active maintainers.

To avoid breaking users' existing clones, we shouldn't do this completely abruptly. One option would be:

1. Create a new branch primary at the current HEAD of master

2. Create a commit on master (and fast-forward merge it into primary) adding instructions to README.md for how to migrate an exsting clone from master to primary. The instructions should work even if master gets deleted on the remote (I have been on the receiving end of such situation before, IIRC I was able to fix my local clone in-place and made partial notes how to do it).

3. Make primary the default branch, update our CI, and then merge syntax-update to primary when syntax-update is ready. At this point master would become unmaintained (and disconnected from CI).

4. After a significant enough time window has passed, delete master.

Does this sound reasonable?

[NoahTheDuke]

I prefer main which I think is the new git default, but otherwise this is doable.

[laniakea64]

👍 main is also more technically precise than master, so main it is then! main branch has been created.

@NoahTheDuke Are there any other collaborators we should ensure are at least pinged on this issue before going further with this?

[NoahTheDuke]

@casey did some work back when I started, and this is upstreamed to vim-polyglot, but otherwise I don't think anyone else has done public work on it.

[laniakea64]

I don't have access to change the default branch of this repo, so @NoahTheDuke we will both need to be available on the same day. If proposed changes look good, can we coordinate this sometime during 21 March, UTC?

[NoahTheDuke]

I cannot make any plans to be online at a given time lol, but you should be able to make new branches in this repo and then I can change the default one we make sure nothing bad will happen.

[laniakea64]

Ah sorry for not being clear, I didn't mean an exact time, just had in mind changing the default branch sometime whenever within a 24-hour-ish or so window of when I push the content changes, to minimize any potential discrepancies. I totally understand being unable to make any plans to be online at a specific time, it's same with me too.

So the proposed changes look good to you? What I wrote in README.md is clear enough & a reasonable writing style?

If looks good I'll take care of pushing the changes to here, to both branches.

[laniakea64]

Actually, think I found & fixed what was making me not quite sure about the README.md changes.

Also, come to think of it, this doesn't have to be done in the order initially proposed: we could change the default branch now, then I push the CI/readme changes to main and fast-forward-merge into master.

So could you please go ahead with change the default branch to main? Thanks!

[NoahTheDuke]

Done!

[laniakea64]

master is now officially stale, so could be slated for deletion anytime now, but...

this is upstreamed to vim-polyglot,

sheerun/vim-polyglot#836 attempt to update vim-polyglot seems to have pulled our master branch?

Who packages vim-just into vim-polyglot? Can we ping them and ask them to pull from our main branch?

[laniakea64]

Who packages vim-just into vim-polyglot?

Trying to research this question myself, it looks like the answer is "no one, it's unmaintained".

The initial packaging was submitted by @NoahTheDuke , but IIUC it has not been touched since. And multiple subsequent pull requests to improve it have only gone ignored for years and counting.

In fact, is vim-polyglot even maintained at all? Last commit was in October 2022, last significant activity was in April 2022, recent issues and PRs are being ignored, and the repo owner looks to have moved on to other projects.

Trying to accommodate unmaintained downstreams in current and future work seems pointless, maybe we shouldn't factor vim-polyglot in deciding when to delete our dead master branch?

[NoahTheDuke]

Woah! That's wild. I don't use polyglot anymore due to size and general annoyance, but I'm still surprised to see it fall into disarray. Thanks for the research.

[laniakea64]

On the subject of the last few comments here, just's documentation about vim-just says -

vim-just is also available from vim-polyglot, a multi-language Vim plugin.

Which implies that the justfile support available in vim-polyglot is same as what someone would get if they installed vim-just directly from our repo. This was true when that sentence was written, but as discussed above, it's no longer the case, and the discrepancy is widening over time.

We've already had at least two issues filed in our repo that ended up being due to the reporter using outdated and unmaintained vim-polyglot packaging of vim-just. If just documentation clearly spelled out that these are not the same, it would be a huge help to giving users a clearer idea of what's what, it would save everyone time and spare everyone from confusion.

I've drafted a possible suggested change - casey/just@f58ff53

@NoahTheDuke Since I wasn't around that part of just and vim-just history, your take on that draft would be appreciated: Do you think it would be reasonable to submit as a pull request to just? Or does it need edited in some way?

[NoahTheDuke]

I think that's a perfectly reasonable note.

[laniakea64]

Deleted branch master (was 2cf3acc).