@@ -270,7 +270,7 @@ To learn more about automated publishing, consult
270
270
# ## Publish prerelease versions {:#publishing-prereleases}
271
271
272
272
As you work on a package, consider publishing it as a prerelease.
273
- Prereleases can be useful when _any_ of the following are true :
273
+ Prereleases can be useful when :
274
274
275
275
* You're actively developing the next major version of the package.
276
276
* You want beta testers for the next release candidate of the package.
@@ -285,12 +285,14 @@ Later, when you release version `2.0.0`, it takes precedence over all
285
285
286
286
As pub prefers stable releases when available, users of a prerelease package
287
287
might need to change their dependency constraints.
288
- For example, if a user wants to test prereleases of version 2.1, then
288
+ For example, if a user wants to test prereleases of version ` 2.1.0` , then
289
289
instead of `^2.0.0` or `^2.1.0` they might specify `^2.1.0-dev.1`.
290
290
291
291
:::note
292
- If a stable package in the dependency graph depends on a prerelease,
293
- then pub chooses that prerelease instead of a stable release.
292
+ While `pub` prefers stable releases the same way it prefers newer versions,
293
+ the version solver does not attempt all solutions and may pick a prerelease,
294
+ even when a resolution that doesn't use prelreases exists.
295
+ Though this rarely happens in practice.
294
296
:: :
295
297
296
298
When you publish a prerelease to pub.dev,
0 commit comments