For the framework we follow Semantic Versioning as defined on http://semver.org/.
A release only containing backwards-compatible bug fixes. A bug fix in that sense is a reverting back functionality to what it has been there in the release before the last release. In case a feature doesn't work as expected, but has been there since a while and developers started to rely on it then it is not a bug fix, but a breaking change. If there is doubt if it's a bug fix or a breaking change fall back to breaking change.
In version 1.2.0 we deployed a new version for every function. In 1.3.0 we stopped doing that, then a bug-fix release would bump the version 1.3.1
If a release adds functionality in a backwards-compatible manner and contains backwards-compatible bug fixes. So whenever a new CLI option is added, a new property exposed in the serverless object passed to plugins this counts as new functionality.
In version 1.2.0 no profile option for the CLI existed and it should be introduced in the next release. Then the next version will be 1.3.0.
Any non-backward compatible changes leads to a major version bump. This includes:
this.serverless
--json
) NOT: standard outputsIf we remove a helper function from the serverless object passed down to a plugin then this is a breaking change since some people might rely on it in custom made plugins.
The Serverless Framework supports the major cloud providers Node.js runtime versions. Support for old Node.js versions will be removed once Cloud providers announce that such runtimes are not supported anymore.
No, since this is a breaking change it should trigger a major version bump to 2.0.0
Yes, this is the purpose of major version bumps. Ideally every breaking change has a clear and well documented migration path. In best case the features were already introduced earlier and upgrading is not a dealbreaker.
No, as we strictly follow Semantic Versioning. The suggested strategy is to add features with minor releases and only do major version bumps when we take out deperecated features. Sometimes this is not possible, but as suggested above then a well documented migration path should come with the release.
Right now we don't provide an option to output a well formated datastructure for a CLI command. Once we have such an option the default CLI output will not be part of the breaking changes list, but rather the datastructure. Also to note here if we add to that datastructure it will not be a breaking change. If we remove or change something from that datastructure it is a breaking change.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。