Version rules, logic, and devicon.json simplification

[ConX]

Hi all,

I thought it would be best to post this proposal as a discussion instead of an issue, as it might require a few iterations before it takes its final form.

Motivation

When I started preparing for my first icon contribution, I wasn't sure which versions to create, and the documentation wasn't clear enough. Given that I like to learn by example, I checked the devicon.json and the icons/ directory to help me figure out any patterns, but that made it even worse, as I quickly identified some inconsistencies. As a result, I have been thinking about how to simplify the identification process of what icon versions a given technology needs to have.

Proposal

The proposal has the following parts:

1. Rules: General rules that are meant to introduce high-level constraints
2. Questions: The minimum number of questions that one should ask themselves to determine which versions one needs to submit.

Rules

1. All .svg files for each technology must be listed in the versions.svg list.
2. There always needs to be an original version.
3. The versions.font list, which contains the versions used when generating the font, shouldn't be empty.

Questions

For a given technology:

1. Is there a multi-color **AND** a plain version icon? Positive examples would be technologies that have logos with multiple colors or gradients, while negative would be simple monochromatic logos.
2. Is there a version for this technology that has **extra** text? The word "extra" here is to differentiate between logos that do not have a version without any letters (e.g., AWS)
3. Is there a line version, or can one be created?

When answering all the questions and in combination with the rules above, there is a truth table that can be used to list precisely which versions need to be added. For a demonstration of the algorithm, I quickly put together this page, where a checked checkmark denotes "Yes" to the answer.

Effects

If the above proposal is accepted, it will result in the following changes:

• devicon.json simplifications:
  • Users won't need to add the versions.svg list in the devicon.json as it can be easily generated by GitHub Actions by the contents of the corresponding icon/ sub-directory for each technology. On the other hand, I think the versions.font list remains useful, as some versions might not look nice as fonts (look a the footnotes on the demo page).
  • Since this algorithm implicitly enforces the priority of the versions, there is no need for the aliases to be defined in the devicon.json. If we still need to have them for consistency purposes (e.g., always have a "plain" font version), this can be automated by the GitHub Actions.
• A devicon.json analyzer script can be used to verify that the provided versions are a valid combination and notify the PR author. The same script can also be used to fix existing violations.

[Panquesito7]

This sounds like an amazing idea! It would make things much easier for both the maintainers and contributors.
Let's see what the others think. If everyone agrees, feel free to start working on it! 🙂

If you need any help, let us know! You can also contact us on our Discord server.