Skip to content
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

Code optimizations that result in smaller SVGs downstream better off as minor version? #1871

Closed
Volker-E opened this issue Dec 5, 2023 · 1 comment
Labels

Comments

@Volker-E
Copy link
Contributor

Volker-E commented Dec 5, 2023

Hi all,
thanks for the recent v3.0.4 and v3.0.5 updates, specifically @SethFalco.

We at Wikimedia Foundation are big long-term fans of SVGO, see a.o. https://www.mediawiki.org/wiki/Manual:Coding_conventions/SVG and myself a task contributor for the repo.

One question that came up in discussions around some package updates, not pinning our versions strictly (aka "svgo": "^3.0.3") has resulted in updating to 3.0.5 in an unrelated patch and with that in a huge number of small changes to the icons: Wouldn't have those recent optimizations been better received downstream as minor version update, for example v3.1.0?

Expected behavior
No patch version should result in downstream major SVG output changes.

Desktop (please complete the following information):

  • SVGO Version 3.0.3 vs 3.0.5
@Volker-E Volker-E added the bug label Dec 5, 2023
@SethFalco
Copy link
Member

SethFalco commented Dec 5, 2023

Hey @Volker-E!

Valid point, this mostly comes down to what we interrupt as a minor change. I had opted to increment the patch version because everything that came through were either improvements to existing plugins, bug fixes, or refactors of existing plugins.

However, there was one new optimization that was introduced as part of an existing default plugin. That's likely what resulted in the changes in your files. In retrospect, I should've incremented minor instead, since it ultimately included a new default optimization:

Regardless, I'd be happy to favor minor over patch more. Sorry for the headache, and thanks for bringing it up!

No patch version should result in downstream major SVG output changes.

I'm not sure what the best way to define major is. However, whenever a new optimization is introduced, regardless of if it's a new or existing plugin, I will increment minor instead of patch in future.


As a side-note, while I understand this is about the semantics/expectations of what would change between versions, just adding a note in case you aren't aware. ^3.0.3 pins the major version only! So when running updates, that would've updated to 3.1.0 anyway. If you want to stay within the same minor version, you want ~3.0.3… though that wouldn't have helped in this case. ^-^'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants