Deprecate master branch completely (remove it)

[EmilyGraceSeville7cf]

master branch must be deprecated in the future, we only have to decide when.

[kbdharun]

I would suggest starting a discussion regarding this in our Gitter/Matrix Chatroom.

[MasterOdin]

The transition to main happened around May 1, 2021 (#5868). I would propose that at this point master gets deprecated immediately to be removed on May 1, 2023, giving all clients a full 2 years since main was made available to make the transition. A follow-up would be to then go through the list of clients on the wiki, and for any that are still using master, create an issue alerting them that master will be removed, and for them to transition.

[kbdharun]

Interestingly, Even our python client uses the master branch. I created this PR tldr-pages/tldr-python-client#200 to update it.

[kbdharun]

I noticed some clients use the master branch version of the zip URL from https://github.com/tldr-pages/tldr-pages.github.io too. Should we keep the branch over there or depreciate it along with this?

[pixelcmtd]

Interestingly, Even our python client uses the master branch.

I think I'll have to do another round of checking every tldr client before we can even think about removing master.

[kbdharun]

Interestingly, Even our python client uses the master branch.

I think I'll have to do another round of checking every tldr client before we can even think about removing master.

Thanks, I am almost done (Just some clients to go), I will add the list here in an hour.

[kbdharun]

Clients to fix:

• https://github.com/Moddus/tldr-python-dash-docset → Use main branch instead of master Moddus/tldr-python-dash-docset#7
• https://github.com/principis/tldr-sharp → Use main branch instead of master principis/tldr-sharp#4
• https://github.com/ronan696/keypirinha-tldr → Use main branch instead of master ronan696/keypirinha-tldr#2
• https://github.com/unInstance/untldr → Use main branch instead of master kovmir/tinytldr#4
• https://github.com/anoopengineer/tldr → Use main branch instead of master anoopengineer/tldr#3
• https://github.com/hterkelsen/tldr → Use main branch instead of master harryterkelsen/tldr#5
• https://github.com/pepa65/tldr-bash-client → tldr: Use main branch instead of master pepa65/tldr-bash-client#17
• https://github.com/avih/tldr-fmt → tldr: Use main branch instead of master avih/tldr-fmt#1
• https://github.com/BrainMaestro/tldr-php → Use main branch instead of master BrainMaestro/tldr-php#14
• https://github.com/kirillseva/tldrrr → Use main branch instead of master kirillseva/tldrrr#1
• https://github.com/k3mist/tldr → Use main branch instead of master k3mist/tldr#1
• https://github.com/tldr-pages/extldr → Use main branch instead of master extldr#24
• https://github.com/mflint/ios-tldr-viewer → Use main branch instead of master mflint/ios-tldr-viewer#38
• https://github.com/YellowApple/tldrb → tldr: Use main branch instead of master YellowApple/tldrb#12
• https://gitlab.com/ve-nt/outfieldr → gitlab.com/ve-nt/outfieldr!2, gitlab.com/ve-nt/outfieldr!3
• https://github.com/iamgodot/py-tldr → Use main branch instead of master iamgodot/py-tldr#1
• https://github.com/HardDie/myTldr → tldr: Use main branch instead of master HardDie/myTldr#2
• https://github.com/luthfianto/rust-tldr →Use main branch instead of master luthfianto/rust-tldr#7
• https://github.com/wlemuel/vim-tldr → Use main branch instead of master wlemuel/vim-tldr#8
• https://github.com/raylee/tldr-sh-client → Use main branch instead of master raylee/tldr-sh-client#49
• https://github.com/lord63/tldr.py → fix: change master branch to main branch lord63/tldr.py#50
• https://github.com/RosalesJ/tldr-ocaml → Use main branch instead of master RosalesJ/tldr-ocaml#4
• https://github.com/porras/tlcr → Use main branch instead of master porras/tlcr#13
• https://github.com/leighmcculloch/tldr → Use tldr main branch instead of master leighmcculloch/tldr#1

[kbdharun]

Done you can check the above list @pixelcmtd

[pixelcmtd]

Done you can check the above list

@kbdharun Just saw this now, gg I've wasted the last 2 or so hours of my life :c

[kbdharun]

Done you can check the above list

@kbdharun Just saw this now, gg I've wasted the last 2 or so hours of my life :c

Oh, 😅 🤣 . That's actually good too. If I accidentally missed something you could have checked.

[kbdharun]

Update: Reminded, the repo owners of the unmerged PRs about the change, I will do it again after 15 days.

[pixelcmtd]

It's 1 May 04:25 in UTC right now. Does anyone have further concerns or can we delete the master branch in a few hours?

[kbdharun]

It's 1 May 04:25 in UTC right now. Does anyone have further concerns or can we delete the master branch in a few hours?

Can we start a discussion regarding this in the chatroom, in order to get other's opinions too.

I think we could do it, and update wiki to reflect the remaining clients here as borked or outdated. Then since we updated client specification too then we can make a release.

[pixelcmtd]

I think we could do it, and update wiki to reflect the remaining clients here as borked or outdated.

I've already spent my last few days thinking about whether to make a table of unmaintained, broken and outdated clients or just mark and move them to the ends of their respective tables.

Could also tie in well with the client spec compliance/certification plans I've been thinking about proposing for months (maybe even years, I've lost track) by now

[kbdharun]

I think we could do it, and update wiki to reflect the remaining clients here as borked or outdated.

I've already spent my last few days thinking about whether to make a table of unmaintained, broken and outdated clients or just mark and move them to the ends of their respective tables.

Yeah that would be the best

Could also tie in well with the client spec compliance/certification plans I've been thinking about proposing for months (maybe even years, I've lost track) by now

Agreed, we should mark if the community clients conform to the client specification too.

@SethFalco and @waldyrious what do you think?

[pixelcmtd]

Oh god, do you really want to turn this into a discussion about that? I was very not ready for that yet, but whatever. So my ideas were basically something along these lines:

• Figure out whether we can put the client spec into a machine-readable/algorithmic/? form
• If yes, do that. Otherwise, make a checklist at the end of the spec with a lot of commands and what they're supposed to do
• Optionally, make a tool that you can give the path to a tldr client and it tells you whether it's compliant (this could probably be a 10 line shell script)
• Sort the client list by compliance
• Spend like 10 minutes of design work making certificate "badges"
• Allow clients that are 100% compliant with a version of the client spec to carry the respective badge (after they've been certified by someone from tldr; each client vendor can open an issue if they think they're compliant and if 2 tldr members/contributors sign off on it, they are listed on the wiki with that compliance and afterwards allowed to carry that badge when advertising their project etc)

[kbdharun]

Allow clients that are 100% compliant with a version of the client spec to carry the respective badge (after they've been certified by someone from tldr; each client vendor can open an issue if they think they're compliant and if 2 tldr members/contributors sign off on it, they are listed on the wiki with that compliance and afterwards allowed to carry that badge when advertising their project etc)

I have been thinking for a while, and it would make sense with this change. How about we limit Wiki editing to collaborators and add an issue template for client authors to request their Client addition or if it's already present then updation of details in the Wiki?

It will also prevent Spam like this one https://github.com/tldr-pages/tldr/wiki/Home/0aff51b61cbf32b281a60622766766ced569032c where somebody edited the NodeJS link, I will revert this now.

[pixelcmtd]

How about we limit Wiki editing to collaborators

Why the f- isn't it right now? Seems kinda obvious, sure.

How about we [...] add an issue template for client authors to request their Client addition or if it's already present then updation of details in the Wiki?

Taking a more incremental approach, we should probably make such an issue template right now.

[SethFalco]

table of unmaintained, broken and outdated clients or just mark and move them to the ends of their respective tables.

Let's not move them to the end of a table.
They should be separated entirely, and out of sight for new users just looking for a client. It'd be better, imo to have the list of maintained clients that follow our client specifications, and then a separate table (in a details tag) of unmaintained clients.

Figure out whether we can put the client spec into a machine-readable/algorithmic/? form

We can use Bats. It's a test framework that enables us to define test suites for bash. In doing so, we can create tests that verify clients meet the interface required by our client specifications. We can test against supported arguments, commands, or even the layout of the output.

Why the f- isn't it right now? Seems kinda obvious, sure.

Because by definition, a "wiki" can be edited by the community.

A collaborative website whose content can be edited by anyone who has access to it.

— https://www.wordnik.com/words/wiki

a website that allows visitors to make changes, contributions, or corrections

— https://www.merriam-webster.com/dictionary/wiki

If something were to be obvious, it would be that it should be open to the public. Though I have nothing against limiting who has write-access to the wiki, I just want to note why it's not "obvious".

[waldyrious]

I agree that the default-to-open aspect of wikis would be the natural expectation. If GitHub's implementation of the concept makes it hard to detect spam edits (which seems to be the case), and if such edits are prevalent (are they?), then I would agree, albeit reluctantly, that it makes sense to close it down a bit.

As for splitting the unmaintained clients — on the one hand, it pains me to contribute to the march towards obsolescence of software that was perfectly functional in the past, and had the ecosystem around it change from underneath their feet, but I suppose that process is both inevitable and to some degree desirable, lest we block progress in the name of conservatism. Blabbering aside, tl;dr: yeah, I won't object to making the move of abandoning the master branch and de-recognizing clients that haven't updated to support the new branch name.

I would prefer if a broader discussion about compliance to the spec was handled in a separate thread, so that this one could be closed once the two steps I mentioned above are taken. Otherwise I'm afraid this already long thread will drag on for even longer.

[pixelcmtd]

Given our usual 12 hour waiting period, I'd suggest removing the branch at 17:00 (or 5 PM if you're wrong) UTC, or 2 hours from now

[pixelcmtd]

I've moved the broken clients from the comment above to the bottom. There are probably more, especially ones that have been archived for a while.