simple-icons-website icon indicating copy to clipboard operation
simple-icons-website copied to clipboard

Add notice about icons that will be removed/renamed

Open ericcornelissen opened this issue 3 years ago • 5 comments

Credits for this idea go to @PeterShaggyNoble


Kind of issue

  • [x] Feature
  • [ ] Bug
  • [ ] Design
  • [ ] Other, namely:

Description

Include an notice in icon cards that informs users that the icon will be removed or renamed in the next major release of simple-icons.

ericcornelissen avatar May 08 '21 21:05 ericcornelissen

I think the first thing we need to decide is whether we want to do this for the website only or also flag breaking changes in the package.

PeterShaggyNoble avatar May 13 '21 15:05 PeterShaggyNoble

If we can build this into the website without adding it to the package, I see no reason why that decision should block this issue. But that's quite a big if. How did you implement this @PeterShaggyNoble ?

ericcornelissen avatar May 13 '21 15:05 ericcornelissen

I currently have a pair of arrays hardcoded into my local build script that I manually update with each new breaking change. Thinking things through a bit, both options are going to create a little more work but I think adding them to the package might offer more benefits. If we add them to the website only then we have to:

  1. Create the PR in the main repo
  2. Add the breaking change to the website repo somehow
  3. Remove all the breaking changes from the website repo after the release

Whereas if we add it to the package, we only have to:

  1. Create a PR for the breaking change in the main repo
  2. Create a second PR in the main repo to add the flag to the JSON

with the first option, I can see us on occasion easily forgetting steps 2 & 3, as it's in a separate repo. Unless 3 can be somehow automated using the release action. Forgetting to remove derprecations wouldn't be a big issue but forgetting to remove renames could be, depending on implementation. And, on the rare occasions that its an outside contributor submitting a breaking change then they're definitely not going to realise they have to make changes in another repo, too.

With the second option, everything's done in the main repo in just 2 steps and has the added benefit of allowing us to expose the flags in the package which would allow us to log* warnings and errors alerting users of breaking changes.

*assuming Node has a console to log them too!

PeterShaggyNoble avatar May 13 '21 16:05 PeterShaggyNoble

I'd definitely be against keeping a manually updated list in this repository for that. I was thinking it could be automated by looking at the icons/*.svg files removed in Pull Requests belonging to the next major release. And in that case I don't see how this would be blocked by a decision in this regard on the package. I'm also not convinced it should be added to the package if it is just so we can display the information on the website.

ericcornelissen avatar May 13 '21 16:05 ericcornelissen

Oh, if it could be automated against the activity in the main repo, that's be incredible. That would then we'd have time to discuss adding flags to the package separately without it blocking anything in the meantime.

PeterShaggyNoble avatar May 18 '21 15:05 PeterShaggyNoble