You can sketch out your project in incredible detail, but in the world of software, you'll hit something you hadn't considered sooner or later. The trick is to anticipate that it'll happen and make sure that the transition is smooth for your end-users. More importantly, nothing should break for your existing users.

When I started SVGBox, the iconsets I had added needed only the fill color to be modified (e.g, the Material UI iconset). That's why there's a fill param. Then, I added an iconset that needed that based on strokes. My solution was that the fill could mean stroke in the context of the icon. But that is problematic for svg-loader method because it loads an icon via XHR, and then injects it into HTML. That means the user has to know whether the icon is fill or stroke to modify the color. Usually, this is not a problem because SVGBox gives you the correct code to use, but nonetheless, it adds to be complexity.

Then, I saw that few icons use gradients, which can't modified by either fill or stroke. Example:

<svg ...>
    <defs>
        <linearGradient x1="8.042%" y1="0%" x2="65.682%" y2="23.865%" id="tail-spin_svg__a">
            <stop stop-color="#000" stop-opacity="0" offset="0%"/>
            <stop stop-color="#000" stop-opacity=".631" offset="63.146%"/>
            <stop stop-color="#000" offset="100%"/>
        </linearGradient>
    </defs>
    ...
</svg>

What was working till now doesn't anymore. The solution here is to use currentColor which basically can be inherited by child elements.

<svg color="red">
    <defs>
        <linearGradient x1="8.042%" y1="0%" x2="65.682%" y2="23.865%" id="tail-spin_svg__a">
            <stop stop-color="currentColor" stop-opacity="0" offset="0%"/>
            <stop stop-color="currentColor" stop-opacity=".631" offset="63.146%"/>
            <stop stop-color="currentColor" offset="100%"/>
        </linearGradient>
    </defs>
    ...
</svg>

It made total sense for the fill/stroke problem, too. I can set currentColor for fill or stroke, so that only color attributes needs to be modified by the user. But the bummer was, it won't be compatible the existing API. I value backwards-compatibility in the sense that nothing should break for existing users. So, here's I solved it:

Existing users who were using s.svgbox.net URLs will work the same way with the same attributes. The new API will use s2.svgbox.net as the subdomain. It will use color attribute name, and will use the currentColor approach.

Hopefully, SVGBox won't be needing any other backward-incompatible changes. And if does, the framework to migrate works rock-solid.