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

Packages: Deprecated: Gutenberg-independent deprecations #9753

Closed
aduth opened this issue Sep 10, 2018 · 2 comments
Closed

Packages: Deprecated: Gutenberg-independent deprecations #9753

aduth opened this issue Sep 10, 2018 · 2 comments
Labels
Needs Decision Needs a decision to be actionable or relevant [Package] Deprecated packages/deprecated [Type] Breaking Change For PRs that introduce a change that will break existing functionality [Type] Enhancement A suggestion for improvement.

Comments

@aduth
Copy link
Member

aduth commented Sep 10, 2018

Related: Discussed during September 4th JavaScript Chat

Currently, all calls to the deprecated function pass a Gutenberg version number at which the feature is to be deprecated. This is sensible within the context of the Gutenberg plugin, but has no meaning in the context of the published npm package.

This raises a few questions (action items denoted by ⚠️):

  • Should npm package releases have a separate schedule for feature deprecation?
    • Currently: No
    • ✅ Operating assumption for intended ideal: No. Preferably, at least one minor version of the package with deprecated message is published (reference).
  • Should npm packages log warnings including the Gutenberg deprecation version?
    • Currently: Yes
    • ⚠️Operating assumption for intended ideal: No. It's suggested that the message be made filterable, with no default Gutenberg references for the published deprecated module messaging. The Gutenberg references should be added by an extension via [???] (implementation undetermined)
  • Should the public API interface of deprecated include plugin and version options?
    • Currently: Yes
    • ⚠️Operating assumption for intended ideal: Unknown. The plugin option is probably unnecessary, though it may be sensible to have some built-in knowledge / messaging of a deprecation removal version. In these cases, it may be required to allow granular extension of specific message fragments (e.g. the variables composing the deprecated message).
@aduth aduth added [Type] Enhancement A suggestion for improvement. Needs Decision Needs a decision to be actionable or relevant [Package] Deprecated packages/deprecated [Type] Breaking Change For PRs that introduce a change that will break existing functionality labels Sep 10, 2018
@paaljoachim
Copy link
Contributor

I see a merged PR here so that I will close this old issue.

@gziolo (Greg I have been pinging you a lot to Andrew's older issues. I do hope that is alright.)

@gziolo
Copy link
Member

gziolo commented Jan 13, 2021

It's less relevant as of today but we could change the package to print the Gutenberg plugin version only inside the plugin. It should be doable by using process.env.GUTENBERG_PHASE === 2 constant check in @wordpress/deprecated. On the other hand, it isn't quite a good match. I would say that it's fine to leave it closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Decision Needs a decision to be actionable or relevant [Package] Deprecated packages/deprecated [Type] Breaking Change For PRs that introduce a change that will break existing functionality [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

3 participants