Closed parkr closed 1 year ago
@parkr I'd rather that we ship a v0.13.0 instead of a v1.0.0 for the following reasons:
The above are my opinions. Your mileage may vary.
Once, we ship a v1.0, the plugin will be considered "stable" as per SemVer protocol and we will not be allowed to change our public Ruby method(s) easily (even though we are not going to be affecting the public API).
This doesn’t apply to our plugins the way it applies to Jekyll core. The API we provide in plugins is all controlled through Jekyll: the input content and the config. I don’t think we’ve ever promised that our plugins would have a stable ruby API, and I don’t think a v1 means that. We’re not in the business of providing a ruby API here.
Bumping the major version when "our own" Ruby code takes a very different and newer approach feels better..
We need to indicate to the user that things could break. Changing our version constraint like we did means users now automatically get v4. This has some breaking changes (like lost support for custom emoji) that may surprise folks without the major version bump as an indicator. It’s not about our code changes, it’s about the collective user experience and whether we have broken any part of previous user-expected behavior.
Is it really that huge an update? The only change is adding support for a modern library alongside legacy library behavior.
the new library has breaking changes, and it’s the new default. We can ship a v0.13.0, but it felt like time that these plugins get called “stable.”
@parkr I recommend waiting for a couple of hours and updating the release date to 2022-11-17 before you merge this because it already the 17th in the rest of the world (incl. east coast U.S)
big upgrade gets a big version bump. closes #125.