我想知道在我的Flutter 应用程序中Dart软件包版本是如何解决的.
比方说,我有一个依赖项foo
,并声明一个依赖项,如下所示:
dependencies:
foo: ^1.2.3
DART Pub如何知道要解决哪个版本/新版本可用时会发生什么情况?
此外,如果我想要将我的Ffltter插件发布到pub.dev,我如何决定何时增加版本的哪个部分?
我想知道在我的Flutter 应用程序中Dart软件包版本是如何解决的.
比方说,我有一个依赖项foo
,并声明一个依赖项,如下所示:
dependencies:
foo: ^1.2.3
DART Pub如何知道要解决哪个版本/新版本可用时会发生什么情况?
此外,如果我想要将我的Ffltter插件发布到pub.dev,我如何决定何时增加版本的哪个部分?
所有这些都可以追溯到DART包版本控制,也就是说,Flutter 翼插件没有区别.
它是以SemVer 2.0.0-rc.1
(Semantic Versioning)为基础的.对于DART包,本发明的要点如下:
<1.0.0 |
>=1.0.0 |
---|---|
0.major.minor+patch |
major.minor.patch |
请注意,Pub还支持由以下符号表示的预发布版本:
<1.0.0 |
>=1.0.0 |
---|---|
0.major.0-prerelease.patch |
major.0.0-prerelease.patch |
示例版本可能是0.6.0-nullsafety.0
(补丁版本为0.6.0-nullsafety.1
)或2.0.0-dev.1
.
Learn more about Dart's package versioning美元.
要对版本解析试图解决的问题有一个基本的了解,您可以通读DART的包版本控制文章的第Resolving shared dependencies节.我将在这里介绍的版本解析方面是caret syntax.
插入符号^
语法是Dart中解析版本的标准语法,与上面的版本控制表密切相关.无论何时使用foo: ^1.0.0
定义依赖项,都需要一些逻辑来确定哪些版本可以从该字符串中解析.
一般来说,^
与up to major versions匹配.这意味着无论何时您的API中有breaking change,您都会希望是bump the major version,因为这样依赖项就不会自动升级到您的下一个包版本.我将try 在表格中再次说明匹配情况:
^0.4.2+1 |
^1.3.0 |
---|---|
>=0.4.2+1 <0.5.0 |
>=1.3.0 <2.0.0 |
如您所见,caret syntax将匹配任何大于或等于当前版本但小于下一个major版本的版本.
请注意,在DART中,预发布版本的处理方式与普通版本不同(不完全符合SemVer规范).你可以找到the source code for Pub's pub_semver
tool on GitHub张.它声明预发布版本与插入符号语法(而不是传统语法)匹配not:
^1.0.0 |
matches version? |
---|---|
1.4.2 |
yes |
1.5.0-beta |
yes |
2.0.0-alpha |
no |
2.0.0 |
no |
Learn more about Dart's package dependencies美元.
pubspec.锁
我很快就想提到Pubspec lock file在DART中解决依赖问题的作用.
我认为有一种简单的方法可以定义如何获取包版本:
pub get
without退出pubspec.锁
(初始获取)将获取latest possible个版本(根据上述规则并且满足共享依赖的所有直接和传递约束).pub get
with现有的pubspec.锁
文件将优先 Select 锁定文件中的锁定版本而不是最新版本(如果它们仍然满足自上次提取以来潜在地新引入的依赖关系的约束).pub upgrade
丢弃现有的pubspec.锁
文件,然后以与初始pub get
相同的方式操作.因此,在应用程序中运行pub get
不会意外获取新版本.当与同事一起工作时,当运行pub get
并在版本控制中包含锁文件时,每个人都会根据pubspec.锁
文件获取相同的版本.
Learn more about lockfiles in Dart美元.
因为the Dart team recommends some best practices for versioning,我想确保将它们直接包含在这里:
Use caret syntax
Specifying dependencies with version ranges is such as^1.6.3
is a good practice because it allows the pub tool to select newer versions of the package when they become available. Also, it places an upper limit on the allowed version, based on an assumption that packages use semantic versions, where any version of path versioned1.x
is compatible, but where a new version2.x
would be a major upgrade that isn’t semantically compatible with1.x
versions.Depend on the latest stable package versions
Usepub upgrade
to update to the latest package versions that your pubspec allows. To identify dependencies in your app or package that aren’t on the latest stable versions, usepub outdated
.Test whenever you update package dependencies
If you runpub upgrade
without updating your pubspec, the API should stay the same and your code should run as before — but test to make sure. If you modify the pubspec and update to a new major version, then you might encounter breaking changes, so you need to test even more thoroughly.