| commit | 3175ba0a58a96fb23f8d68b5f5c44d1a5b30cc16 | [log] [tgz] |
|---|---|---|
| author | dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> | Thu Feb 01 16:28:03 2024 +0000 |
| committer | GitHub <noreply@github.com> | Thu Feb 01 16:28:03 2024 +0000 |
| tree | e6c393f3c3e9909498b188637037a7d4b8fe0e10 | |
| parent | 45721813dea1591a7689f93762afa358cbf260c7 [diff] |
Bump dart-lang/setup-dart from 1.6.0 to 1.6.2 (#98) Bumps [dart-lang/setup-dart](https://github.com/dart-lang/setup-dart) from 1.6.0 to 1.6.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dart-lang/setup-dart/releases">dart-lang/setup-dart's releases</a>.</em></p> <blockquote> <h2>v1.6.2</h2> <ul> <li>Switch to running the workflow on <code>node20</code> from <code>node16</code>. See also <a href="https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/">Transitioning from Node 16 to Node 20</a>.</li> </ul> <h2>v1.6.1</h2> <ul> <li>Updated the google storage url for <code>main</code> channel releases.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/dart-lang/setup-dart/blob/main/CHANGELOG.md">dart-lang/setup-dart's changelog</a>.</em></p> <blockquote> <h2>v1.6.2</h2> <ul> <li>Switch to running the workflow on <code>node20`` from </code>node16`. See also <a href="https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/">Transitioning from Node 16 to Node 20</a>.</li> </ul> <h2>v1.6.1</h2> <ul> <li>Updated the google storage url for <code>main</code> channel releases.</li> </ul> <h2>v1.6.0</h2> <ul> <li>Enable provisioning of the latest Dart SDK patch release by specifying just the major and minor version (e.g. <code>3.2</code>).</li> </ul> <h2>v1.5.1</h2> <ul> <li>No longer test the <code>setup-dart</code> action on pre-2.12 SDKs.</li> <li>Upgrade JS interop code to use extension types (the new name for inline classes).</li> <li>The upcoming rename of the <code>be</code> channel to <code>main</code> is now supported with forward compatibility that switches when the rename happens.</li> </ul> <h2>v1.5.0</h2> <ul> <li>Re-wrote the implementation of the action into Dart.</li> <li>Auto-detect the platform architecture (<code>x64</code>, <code>ia32</code>, <code>arm</code>, <code>arm64</code>).</li> <li>Improved the caching and download resilience of the sdk.</li> <li>Added a new action output: <code>dart-version</code> - the installed version of the sdk.</li> </ul> <h2>v1.4.0</h2> <ul> <li>Automatically create OIDC token for pub.dev.</li> <li>Add a reusable workflow for publishing.</li> </ul> <h2>v1.3.0</h2> <ul> <li>The install location of the Dart SDK is now available in an environment variable, <code>DART_HOME</code> (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/43">#43</a>).</li> <li>Fixed an issue where cached downloads could lead to unzip issues on self-hosted runners (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/35">#35</a>).</li> </ul> <h2>v1.2.0</h2> <ul> <li>Fixed a path issue impacting git dependencies on Windows.</li> </ul> <h2>v1.1.0</h2> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/dart-lang/setup-dart/commit/fedb1266e91cf51be2fdb382869461a434b920a3"><code>fedb126</code></a> switch to using node20 (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/122">#122</a>)</li> <li><a href="https://github.com/dart-lang/setup-dart/commit/ca7e6fee45ffbd82b555a7ebfc236d2c86439f5b"><code>ca7e6fe</code></a> update the changelog; prep to release 1.6.1 (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/120">#120</a>)</li> <li><a href="https://github.com/dart-lang/setup-dart/commit/c1b2cdbfafc77480d10fe0246ef4dd2f83a9e7b7"><code>c1b2cdb</code></a> Clean up after renaming the be channel to main. (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/115">#115</a>)</li> <li><a href="https://github.com/dart-lang/setup-dart/commit/49b0b8e0a88f72a8fdf1319a41cc261cec63c3c7"><code>49b0b8e</code></a> Bump actions/checkout from 3 to 4 in README.md (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/117">#117</a>)</li> <li><a href="https://github.com/dart-lang/setup-dart/commit/7f54cd0cee53e120db0d1fce4196b7772ebd6f6e"><code>7f54cd0</code></a> Bump <code>@âactions/http-client</code> from 2.1.1 to 2.2.0 (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/112">#112</a>)</li> <li><a href="https://github.com/dart-lang/setup-dart/commit/6e2fe379bd3c8a39facc503f4494396e0de36f13"><code>6e2fe37</code></a> Bump dart-lang/setup-dart from 1.5.1 to 1.6.0 (<a href="https://redirect.github.com/dart-lang/setup-dart/issues/113">#113</a>)</li> <li>See full diff in <a href="https://github.com/dart-lang/setup-dart/compare/b64355ae6ca0b5d484f0106a033dd1388965d06d...fedb1266e91cf51be2fdb382869461a434b920a3">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details>
Handles version numbers and version constraints in the same way that pub does.
The semantics here very closely follow the Semantic Versioning spec version 2.0.0-rc.1. It differs from semver in a few corner cases:
Version ordering does take build suffixes into account. This is unlike semver 2.0.0 but like earlier versions of semver. Version 1.2.3+1 is considered a lower number than 1.2.3+2.
Since a package may have published multiple versions that differ only by build suffix, pub still has to pick one of them somehow. Semver leaves that issue unresolved, so we just say that build numbers are sorted like pre-release suffixes.
Pre-release versions are excluded from most max ranges. Let's say a user is depending on “foo” with constraint >=1.0.0 <2.0.0 and that “foo” has published these versions:
1.0.01.1.01.2.02.0.0-alpha2.0.0-beta2.0.02.1.0Versions 2.0.0 and 2.1.0 are excluded by the constraint since neither matches <2.0.0. However, since semver specifies that pre-release versions are lower than the non-prerelease version (i.e. 2.0.0-beta < 2.0.0, then the <2.0.0 constraint does technically allow those.
But that‘s almost never what the user wants. If their package doesn’t work with foo 2.0.0, it's certainly not likely to work with experimental, unstable versions of 2.0.0's API, which is what pre-release versions represent.
To handle that, < version ranges don't allow pre-release versions of the maximum unless the max is itself a pre-release, or the min is a pre-release of the same version. In other words, a <2.0.0 constraint will prohibit not just 2.0.0 but any pre-release of 2.0.0. However, <2.0.0-beta will exclude 2.0.0-beta but allow 2.0.0-alpha. Likewise, >2.0.0-alpha <2.0.0 will exclude 2.0.0-alpha but allow 2.0.0-beta.
Pre-release versions are avoided when possible. The above case handles pre-release versions at the top of the range, but what about in the middle? What if “foo” has these versions:
1.0.01.2.0-alpha1.2.01.3.0-experimentalWhen a number of versions are valid, pub chooses the best one where “best” usually means “highest numbered”. That follows the user‘s intuition that, all else being equal, they want the latest and greatest. Here, that would mean 1.3.0-experimental. However, most users don’t want to use unstable versions of their dependencies.
We want pre-releases to be explicitly opt-in so that package consumers don't get unpleasant surprises and so that package maintainers are free to put out pre-releases and get feedback without dragging all of their users onto the bleeding edge.
To accommodate that, when pub is choosing a version, it uses priority order which is different from strict comparison ordering. Any stable version is considered higher priority than any unstable version. The above versions, in priority order, are:
1.2.0-alpha1.3.0-experimental1.0.01.2.0This ensures that users only end up with an unstable version when there are no alternatives. Usually this means they‘ve picked a constraint that specifically selects that unstable version -- they’ve deliberately opted into it.
There is a notion of compatibility between pre-1.0.0 versions. Semver deems all pre-1.0.0 versions to be incompatible. This means that the only way to ensure compatibility when depending on a pre-1.0.0 package is to pin the dependency to an exact version. Pinned version constraints prevent automatic patch and pre-release updates. To avoid this situation, pub defines the “next breaking” version as the version which increments the major version if it's greater than zero, and the minor version otherwise, resets subsequent digits to zero, and strips any pre-release or build suffix. For example, here are some versions along with their next breaking ones:
0.0.3 -> 0.1.0 0.7.2-alpha -> 0.8.0 1.2.3 -> 2.0.0
To make use of this, pub defines a “^” operator which yields a version constraint greater than or equal to a given version, but less than its next breaking one.