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

💎 v0.13.0 #135

Merged
merged 1 commit into from
Nov 19, 2022
Merged

💎 v0.13.0 #135

merged 1 commit into from
Nov 19, 2022

Conversation

parkr
Copy link
Member

@parkr parkr commented Nov 16, 2022

big upgrade gets a big version bump. closes #125.

@parkr parkr requested a review from ashmaroli November 16, 2022 18:01
@ashmaroli
Copy link
Member

ashmaroli commented Nov 16, 2022

@parkr I'd rather that we ship a v0.13.0 instead of a v1.0.0 for the following reasons:

  • 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).
  • Is it really that huge a update? The only change is adding support for a modern library alongside legacy library behavior.
  • Bumping the major version when "our own" Ruby code takes a very different and newer approach feels better..

The above are my opinions. Your mileage may vary.

@parkr
Copy link
Member Author

parkr commented Nov 17, 2022

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.”

@ashmaroli
Copy link
Member

@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)

@parkr parkr changed the title 💎 v1.0.0 💎 v0.13.0 Nov 19, 2022
@parkr parkr merged commit 1443020 into master Nov 19, 2022
@parkr parkr deleted the release-1-0-0 branch November 19, 2022 07:54
@jekyll jekyll locked and limited conversation to collaborators Nov 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Time for a new release
3 participants