mirror of
https://hk.gh-proxy.com/https://github.com/NodeBB/nodebb.org.git
synced 2025-10-04 08:53:29 +08:00
7 lines
No EOL
3.8 KiB
HTML
7 lines
No EOL
3.8 KiB
HTML
<p>Over the years, NodeBB has amassed quite a collection of plugins, most of which were published to npm and listed in the "Manage Plugins" page in the admin control panel.</p><p>With the release of v2.0.0, we received some reports that the plugin directory was now empty.</p><p><strong>This was intentionally done</strong>, for a number of reasons—read on!</p><h2>Changes to Plugin Compatibility</h2><p>Plugins are encouraged to maintain a property in their <code>package.json</code> called <code>nbbpm</code>. Contained inside this property is a field called <code>compatibility</code>, which is a <a href="https://semver.org/">semantic versioning range</a> of NodeBB versions that the plugin is supposed to be compatible with<sup>1</sup>.</p><p>For example, a plugin may have the following in their <code>config.json</code>:</p><pre>{
|
|
...
|
|
"nbbpm": {
|
|
"compatibility": "^1.17.0"
|
|
}
|
|
...
|
|
}</pre><p>This directive instructs the NodeBB Package Manager (nbbpm) that the plugin is compatible with NodeBB v1.17.0 and up.</p><p>The unofficial standard was to use the carat symbol in the range, which—for the above example—meant that the plugin is compatible with NodeBB versions v1.17.0 through to v2.0.0 (not inclusive of v2.0.0).</p><p>It's because of that exclusivity that meant that all existing plugins (or at least those that reported their compatibility) were no longer listed in v2.0.0.</p><p>If you maintain a plugin and would like to see your plugin in the list again:</p><ol><li>Run through <a href="https://nodebb.org/blog/migration-guide-for-v2/">the migration guide</a>—make sure your plugin is actually compatible!</li><li>Append <code>|| ^2.0.0</code> your compatibility string</li></ol><h2>Adoption of Semver</h2><p>In the v1.x releases of NodeBB, we did not strictly follow Semantic Versioning.</p><p>We would wilfully include breaking changes in <strong>minor</strong> releases, and <strong>patch</strong> releases could contain new and backwards-compatible features. <strong>Major</strong> releases were not done regularly, because we felt that the incrementing of the major version number signified that something <em>big</em> had changed.</p><p>We ended up doing just that with the release of version 2—webpack changes caused a great number of plugins to need adjustment.</p><p>However, in the end, a number is just a number, and given the semver ranges in compatibility, <em>it makes sense to adopt semantic versioning for NodeBB core as well</em>.</p><p>Going forward, the NodeBB release behaviour will be as follows—</p><ul><li><strong>Patch </strong>releases<ul><li>will <strong>not</strong> be constrained to a specific day, and can occur at any time</li><li>will occur much more frequently than before</li><li>will contain only bug fixes</li><li>will contain fewer (if any) upgrade side-effects</li></ul></li><li><strong>Minor</strong> releases<ul><li>will continue to be restricted to Wednesdays</li><li>will contain new features and backwards-compatible changes to existing features</li><li>will contain deprecations to existing features (for removal in the next major version)</li></ul></li><li><strong>Major</strong> releases<ul><li>will be restricted to Wednesdays</li><li>will contain breaking changes and removal of features (that were deprecated in an earlier minor version release)</li></ul></li></ul><h1>Notes</h1><ol><li>Occasionally, plugin developers will put <code>*</code> as their compatibility string, which means the plugin will always show up as compatible with all versions of NodeBB. Don't do this—we'll probably guard against this if it gets abused.</li></ol><ul><li>Photo by <a href="https://unsplash.com/@ashkfor121?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Ashkan Forouzani</a> on <a href="https://unsplash.com/s/photos/puzzle?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></li></ul> |
