Semantic versions rules? about browser-logos HOT 6 CLOSED

how semantic rules work on this project? ... Could you please explain a little bit?

@soullivaneuh Sure!

MAJOR version when you make incompatible API changes

Major versions are released every time a path is broken (e.g.: a directory is renamed or moved into archive/ without having a replacement). This is done because I consider that to be a breaking change in the "API" as people who depend on that path will no longer have it.

MINOR version when you add functionality in a backwards-compatible manner

Minor versions are released mainly when the SVG version of a logo and/or a new logo is added.

PATCH version when you make backwards-compatible bug fixes

Patch versions are released when typos or links are fixed, images are further losslessly optimized, a better version of a logo is added by just replacing the existing images, etc..

I hope this helps!

I was on 3.* and just see you are on v22.

Yes, things move fast nowadays! :D

from browser-logos.

Thanks for the explanation. :-)

I think this should be added on the doc. 👍

I completly understand the new major for moving file, but you have to push a lot of them. Why not use a more BC keep method? Let me explain my suggestion:

Imagine you are on v1.0.x and you want to archive a logo. You could

• Move the logo on the archive folder.
• Create a symbolic link of the old file, pointing to the archive folder (git and github manage symlinks like a charm).

Then, the old logo is archived but still accessible from user. Them, you can push v1.1 instead of v2.0.

When you have a lot of deprecated logos and want to clean up, then you can create a new major.

What do you think?

BTW, deleted/moved logos should be marked in the Changelog IMHO.

from browser-logos.

Create a symbolic link of the old file, pointing to the archive folder... them, you can push v1.1 instead of v2.0....

When you have a lot of deprecated logos and want to clean up, then you can create a new major

@soullivaneuh That would just complicate things a lot without any real benefit as far as I see. Plus, you're just prolonging the inevitable, namely, releasing new major versions. Also, given enough time, you will still end up at versions such as 35.y.z.

deleted/moved logos should be marked in the Changelog

That is usually stated (e.g.: Move X logo into the archive/), and if users want more detailed information, they can just read the commit messages or look at the commits.

from browser-logos.

That would just complicate things a lot without any real benefit as far as I see.

The benefit for user would be to have new update without have to check new majore every week. :-)

Also, given enough time, you will still end up at versions such as 35.y.z.

Not 35, but a lower number, less major versions...

But I understand, this is harder to maintain, this is just a suggestion. ;-)

from browser-logos.

have to check new majore every week. :-)

@soullivaneuh I don't think that's a big problem. From what I've seen, most users only care about the main browsers. Plus, when those browsers update their logos it is usually known, therefore, users will most probably only check / update at that point.

this is just a suggestion.

Sure thing, suggestions are always welcomed! 👍

from browser-logos.

deleted/moved logos should be marked in the Changelog IMHO.

Updated the CHANGELOG and the releases. ✨

from browser-logos.