mirror of
https://github.com/dart-lang/sdk
synced 2024-07-20 18:05:01 +00:00
[docs] Misc minor cleanup to migrated wiki docs
Fixes a few minor issues relating to outdated links, spelling, Markdown formatting, word choice, etc. Bug: https://github.com/dart-lang/sdk/issues/54066 Change-Id: Ic7b9b33b27d2ce2c30f9b1fe17b0bc91873ecfb7 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369764 Reviewed-by: Nate Bosch <nbosch@google.com> Reviewed-by: Devon Carew <devoncarew@google.com> Commit-Queue: Devon Carew <devoncarew@google.com>
This commit is contained in:
Parker Lougheed
Commit Queue
parent
82a3006220
commit
8716461eaf
|
|
@ -17,21 +17,21 @@ When adding new third party source dependencies please be very careful. Make sur
|
|||
For example, a compiler's license might allow using it to compile our binary, but could be too restrictive to allow using its source code as part of the source code for a Dart SDK tool.
|
||||
You must add a README.google if you check in third-party code, and note any local changes that have been applied to the code (see below for a template). Please cc dart-engprod@google.com on any third-party additions.
|
||||
|
||||
If you need to discuss license issues to make sure that a license is compatible please reach out to the legal team at google or talk with dart-engprod@google.com who can guide you to the right
|
||||
If you need to discuss license issues to make sure that a license is compatible please reach out to the legal team at Google or talk with dart-engprod@google.com who can guide you to the right
|
||||
person. Please refrain from speculating about licenses or make assumptions about what you may and may not do. If in doubt you should ask. If you are not a Google employee, contact a Dart team member who is.
|
||||
|
||||
We have a few rules to make sure that we can continue to build older versions of the SDK even if people delete or rewrite the history of repositories containing our third-party dependencies. There are two options for using repositories not hosted under https://github.com/dart-lang/ or https://github.com/google/:
|
||||
|
||||
1. Move it to the dart-lang org, or fork it there. Moving is better than forking since it avoids fragmented versions. If you do fork, please state in the README that this is used for pulling in as a DEPS, don't make local changes, and be sure to not publish to pub from the dart-lang fork.
|
||||
|
||||
2. Get the github repo mirrored on the dart.googlesource.com git server, and pull the dependency from there. This is the same way we do normal dependencies from dart-lang (see below), with one important exception:
|
||||
2. Get the GitHub repo mirrored on the dart.googlesource.com git server, and pull the dependency from there. This is the same way we do normal dependencies from dart-lang (see below), with one important exception:
|
||||
**For security reasons, all code pulled in to build the Dart SDK must be reviewed by Google employees, no matter where it comes from.** This means that you, or a Google employee, need to do an initial review of all code up to and including the commit you put in the DEPS file for all external packages.
|
||||
|
||||
All external packages must be pinned to a fixed commit (revision) in the DEPS file. If you update the DEPS to pin a newer version, you need to do another review of the changes between the two revisions. You can upload the review (of the changes in the dependency, not just the change in the DEPS file) to https://dart-review.googlesource.com for easy reviewing, and upstream any fixes in this dependency, before pinning the new version of the dependency.
|
||||
|
||||
For all dependencies on GitHub, we need a mirror. File a GitHub issue labeled `area-infrastructure` (https://dartbug.com) requesting a mirror. The mirrors go to `https://dart.googlesource.com/external/github.com/<org>/<repo>.git`. Once the mirror is set up, you can commit your changes to the DEPS file pointing at the github mirror.
|
||||
For all dependencies on GitHub, we need a mirror. File a GitHub issue labeled `area-infrastructure` (https://dartbug.com) requesting a mirror. The mirrors go to `https://dart.googlesource.com/external/github.com/<org>/<repo>.git`. Once the mirror is set up, you can commit your changes to the DEPS file pointing at the GitHub mirror.
|
||||
|
||||
While you wait for the mirror to get set up, you can add the dependency to the DEPS file pointing directly to `http://github.com/<org>/<repo>.git`. This will let you develop against the dependency locally, but don't commit this.
|
||||
While you wait for the mirror to get set up, you can add the dependency to the DEPS file pointing directly to `https://github.com/<org>/<repo>.git`. This will let you develop against the dependency locally, but don't commit this.
|
||||
|
||||
# Rolling dependencies
|
||||
|
||||
|
|
|
|||
|
|
@ -7,15 +7,15 @@
|
|||
|
||||
## Branches and work flows
|
||||
|
||||
We have a rather simple branch setup for the dart project. Normally, everything is developed on the master branch. Features that are not yet ready for prime time are hidden under a flag, and enabled when sufficient stability has been proven. We occasionally create feature branches for landing big and disruptive changes. In addition to that, we have our dev, beta, and stable branches used for releasing the sdk.
|
||||
We have a rather simple branch setup for the dart project. Normally, everything is developed on the main branch. Features that are not yet ready for prime time are hidden under a flag, and enabled when sufficient stability has been proven. We occasionally create feature branches for landing big and disruptive changes. In addition to that, we have our dev, beta, and stable branches used for releasing the sdk.
|
||||
|
||||
In summary, we have in four main branches:
|
||||
|
||||
* **[master](https://github.com/dart-lang/sdk/blob/master/tools/VERSION)**:
|
||||
* **[main](https://github.com/dart-lang/sdk/blob/main/tools/VERSION)**:
|
||||
Used for "everyday" development; land your CLs here.
|
||||
|
||||
* **[dev](https://github.com/dart-lang/sdk/blob/dev/tools/VERSION)**:
|
||||
Populated from the master branch via full pushes, usually twice a week. Only in emergencies are [cherry picks](Cherry-picks-to-a-release-channel.md) landed on the dev channel. Don't land CLs here. Released via [dev channel builds](https://dart.dev/tools/sdk/archive#dev-channel).
|
||||
Populated from the main branch via full pushes, usually twice a week. Only in emergencies are [cherry picks](Cherry-picks-to-a-release-channel.md) landed on the dev channel. Don't land CLs here. Released via [dev channel builds](https://dart.dev/tools/sdk/archive#dev-channel).
|
||||
|
||||
* **[beta](https://github.com/dart-lang/sdk/blob/beta/tools/VERSION)**:
|
||||
Populated from the dev branch via full pushes, usually once a month, or via [cherry picks](Cherry-picks-to-a-release-channel.md). Don't land CLs here. Released via [beta channel builds](https://dart.dev/tools/sdk/archive#beta-channel).
|
||||
|
|
@ -27,9 +27,9 @@ In summary, we have in four main branches:
|
|||
## Release cycle
|
||||
Our normal release cycle is roughly 2 months long, but we don't make any guarantees, i.e., we may ship early if we feel that the stability is good or we may ship late if it is not. We don't normally follow a feature driven release cycle, but in some cases for larger changes to the language we may postpone a release to get all tools in sync.
|
||||
|
||||
During the entire cycle we do full merges of master to dev, basically releasing a green build from master on dev roughly twice a week. In case of bugs found quickly we do another full push.
|
||||
During the entire cycle we do full merges of main to dev, basically releasing a green build from main on dev roughly twice a week. In case of bugs found quickly we do another full push.
|
||||
|
||||
We spend the last ~2 weeks of the cycle stabilizing the beta channel, starting with a full push of the latest dev release to beta. We only cherry picking critical fixes to the beta channel. People continue working on the master branch and dev releases will continue to be released. In this 2 week period we do multiple batches of cherry picks a week, and release those on the beta channel. We call this cherry-pick season.
|
||||
We spend the last ~2 weeks of the cycle stabilizing the beta channel, starting with a full push of the latest dev release to beta. We only cherry picking critical fixes to the beta channel. People continue working on the main branch and dev releases will continue to be released. In this 2 week period we do multiple batches of cherry picks a week, and release those on the beta channel. We call this cherry-pick season.
|
||||
|
||||
Once we have something that looks good we merge it to stable and release it there. During the 2 months we do patch security, crash and critical bug releases on stable based on the latest stable version.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ If you are running Debian/Ubuntu, you can obtain a cross-compiler by doing the f
|
|||
$ sudo apt-get install g++-arm-linux-gnueabihf # For 32-bit ARM (ARMv7)
|
||||
$ sudo apt-get install g++-aarch64-linux-gnu # For 64-bit ARM (ARMv8)
|
||||
$ sudo apt-get install g++-riscv64-linux-gnu # For 64-bit RISC-V (RV64GC)
|
||||
```
|
||||
```
|
||||
|
||||
## Android
|
||||
|
||||
|
|
|
|||
|
|
@ -31,13 +31,13 @@ Run gclient sync to install the Android NDK and SDK. This may take 10 minutes or
|
|||
|
||||
# Building for Android
|
||||
|
||||
Once you’ve set up your build tree, you can build the Dart VM for Android by using the standard Dart build script with the addition of the --os android build flag:
|
||||
Once you've set up your build tree, you can build the Dart VM for Android by using the standard Dart build script with the addition of the --os android build flag:
|
||||
|
||||
`$ tools/build.py --no-goma --arch=arm,arm64,ia32,x64 --os=android runtime`
|
||||
|
||||
# Testing the result
|
||||
|
||||
Adding “adb” to your path
|
||||
Adding `adb` to your path
|
||||
|
||||
For convenience, add the path to the adb tool to your shell PATH:
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ or
|
|||
|
||||
`$ adb -s emulator-name emu kill ← if there is more than one emulator running`
|
||||
|
||||
## Running the Dart VM on an Android device ##
|
||||
## Running the Dart VM on an Android device
|
||||
|
||||
First, make sure that the "USB Debugging" mode is enabled by navigating to Settings > Developer options > USB debugging. The box should be checked. You may need to have root on the device.
|
||||
|
||||
|
|
@ -110,4 +110,4 @@ Now, you can copy dart and hello.dart to the device as above. If an emulator is
|
|||
|
||||
# Notes
|
||||
|
||||
The only effect of the “target_os” line in the Dart .gclient configuration file is to install the Android tools. Despite what the name “target_os” implies, the target_os line does not affect which OS is targeted. Therefore, once you’ve installed the Android tools you can (and should) leave the target_os = [“android”] line in place even when switching back and forth between building for Android and building for Linux.
|
||||
The only effect of the `target_os` line in the Dart `.gclient` configuration file is to install the Android tools. Despite what the name `target_os` implies, the target_os line does not affect which OS is targeted. Therefore, once you've installed the Android tools you can (and should) leave the `target_os = ["android"]` line in place even when switching back and forth between building for Android and building for Linux.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
[Building the standalone VM only](#standalone)
|
||||
|
||||
<a name="dependencies"/>
|
||||
<a id="dependencies"></a>
|
||||
|
||||
# Dependencies
|
||||
|
||||
|
|
@ -50,17 +50,17 @@ export PATH="$PATH:$PWD/depot_tools"
|
|||
|
||||
## Windows
|
||||
|
||||
[Install Visual Studio](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#visual-studio) (2017 or newer). Make sure to install "Desktop development with C++" component.
|
||||
[Install Visual Studio](https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#visual-studio) (2017 or newer). Make sure to install "Desktop development with C++" component.
|
||||
|
||||
You must have Windows 10 SDK installed. This can be installed separately or by checking the appropriate box in the Visual Studio Installer.
|
||||
|
||||
The SDK Debugging Tools must also be installed. If the Windows 10 SDK was installed via the Visual Studio installer, then they can be installed by going to: Control Panel → Programs → Programs and Features → Select the “Windows Software Development Kit” → Change → Change → Check “Debugging Tools For Windows” → Change. Or, you can download the standalone SDK installer and use it to install the Debugging Tools.
|
||||
The SDK Debugging Tools must also be installed. If the Windows 10 SDK was installed via the Visual Studio installer, then they can be installed by going to: Control Panel → Programs → Programs and Features → Select the "Windows Software Development Kit" → Change → Change → Check "Debugging Tools For Windows" → Change. Or, you can download the standalone SDK installer and use it to install the Debugging Tools.
|
||||
|
||||
Install Chromium's depot tools following [this](http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up) or [this](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#install) instructions.
|
||||
Install Chromium's depot tools following [this](http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up) or [this](https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#install) instructions.
|
||||
|
||||
**Important:** If you are not a Googler make sure to set `DEPOT_TOOLS_WIN_TOOLCHAIN` system variable to `0` otherwise depot tools will attempt to pull down a Google-internal toolchain instead of using a local installation of Visual Studio.
|
||||
|
||||
<a name="source"/>
|
||||
<a id="source"></a>
|
||||
|
||||
# Getting the source
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ Note: If you do not have emscripten, you can update your `.gclient` file to pull
|
|||
},
|
||||
```
|
||||
|
||||
<a name="building"/>
|
||||
<a id="building"></a>
|
||||
|
||||
# Building
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ cd sdk
|
|||
./tools/build.py --mode release --arch x64 create_sdk
|
||||
```
|
||||
|
||||
The output will be in `out/ReleaseX64/dart-sdk` on Linux and Windows, and `xcodebuild/ReleaseX64/dart-sdk` on MacOS.
|
||||
The output will be in `out/ReleaseX64/dart-sdk` on Linux and Windows, and `xcodebuild/ReleaseX64/dart-sdk` on macOS.
|
||||
|
||||
Build the 32-bit SDK:
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ Build the 32-bit SDK:
|
|||
cd sdk
|
||||
./tools/build.py --mode release --arch ia32 create_sdk
|
||||
```
|
||||
The output will be in `out/ReleaseIA32/dart-sdk` on Linux and Windows, or `xcodebuild/ReleaseIA32/dart-sdk` on MacOS.
|
||||
The output will be in `out/ReleaseIA32/dart-sdk` on Linux and Windows, or `xcodebuild/ReleaseIA32/dart-sdk` on macOS.
|
||||
|
||||
See also [Building Dart SDK for ARM or RISC-V](Building-Dart-SDK-for-ARM-or-RISC-V.md).
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ See also [Building Dart SDK for ARM or RISC-V](Building-Dart-SDK-for-ARM-or-RISC
|
|||
|
||||
By default the build and test scripts select the debug binaries. You can build and test the release version of the VM by specifying `--mode=release` or both debug and release by specifying `--mode=all` on the respective `build.py` and `test.py` command lines. This can be shortened to `-mrelease` or `-m release`, and the architecture can be specified with `--arch=x64` or `-a x64`, the default. Other architectures, like `ia32`, `arm`, and `arm64` are also supported.
|
||||
|
||||
We recommend that you use a local file system at least for the output of the builds. The output directory is `out` on linux, `xcodebuild` on Mac OS, and `build` on Windows. If your code is in some NFS partition, you can link the `out` directory to a local directory:
|
||||
We recommend that you use a local file system at least for the output of the builds. The output directory is `out` on linux, `xcodebuild` on macOS, and `build` on Windows. If your code is in some NFS partition, you can link the `out` directory to a local directory:
|
||||
```bash
|
||||
|
||||
$ cd sdk/
|
||||
|
|
@ -143,7 +143,7 @@ Your Visual Studio executable command may have a different name from the standar
|
|||
|
||||
## Building on Windows with Visual Studio 2015
|
||||
Gyp should autodetect the version of Visual Studio you have, and produce solution files in the correct format.
|
||||
If this is not happening, then set environment variable gyp\_msvs\_version to 2015.
|
||||
If this is not happening, then set environment variable `gyp_msvs_version` to `2015`.
|
||||
|
||||
For example, this will produce Visual Studio 2015-compliant solution files:
|
||||
```bash
|
||||
|
|
@ -244,7 +244,7 @@ Some common problems you might get when running tests for the first time:
|
|||
|
||||
* Other options include using ssh X tunneling (`ssh -Y`), NX, VNC, setting up `xhost` and exporting the DISPLAY environment variable, or simply running tests locally.
|
||||
|
||||
<a name="standalone"/>
|
||||
<a id="standalone"></a>
|
||||
|
||||
# Building the standalone VM only
|
||||
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ This is a patch release that:
|
|||
...
|
||||
```
|
||||
|
||||
Link to your cherry-pick request as subsequently filed below. You can upload the changelist again with the final link once the github issue has been filed. The cherry-pick request on github is often more useful for users than the original bug, since it explains the rationale concisely and links to the underlying bug for more information.
|
||||
Link to your cherry-pick request as subsequently filed below. You can upload the changelist again with the final link once the GitHub issue has been filed. The cherry-pick request on GitHub is often more useful for users than the original bug, since it explains the rationale concisely and links to the underlying bug for more information.
|
||||
|
||||
If the cherry-pick is infrastructure only and is invisible to users, the `Changelog-Exempt: ...` footer exempts the change from the changelog requirement.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,9 +7,9 @@
|
|||
|
||||
There are several ways to contribute code in GitHub, for example
|
||||
|
||||
1. forking and creating pull request from a forked repo (https://help.github.com/articles/fork-a-repo)
|
||||
1. branching within the main repo, and doing pull requests from one branch to another.
|
||||
1. working on a local branch, creating a code review using Gerrit, push directly into master (this article).
|
||||
1. Forking and creating pull request from a forked repo (https://help.github.com/articles/fork-a-repo)
|
||||
1. Branching within the main repo, and doing pull requests from one branch to another.
|
||||
1. Working on a local branch, creating a code review using Gerrit, push directly into main (this article).
|
||||
|
||||
## Step 1: get the source
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ There is a `codereview.settings` file in the repo to configure things automatica
|
|||
|
||||
## Step 3: Create a branch for your new changes
|
||||
|
||||
Pick a branch name not existing locally nor in the remote repo, we recommend that you use your user name as a prefix to make things simpler.
|
||||
Pick a branch name not existing locally nor in the remote repo, we recommend that you use your username as a prefix to make things simpler.
|
||||
|
||||
> cd sdk # the repo created above
|
||||
> git checkout -b uname_example # new branch
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ export UBSAN_SYMBOLIZER_PATH="$PWD/buildtools/linux-x64/clang/bin/llvm-symbolize
|
|||
./tools/sdks/dart-sdk/bin/dart ./tools/test.dart -n dartk-linux-release-x64 -N dartk-ubsan-linux-release-x64
|
||||
```
|
||||
|
||||
The handle_segv=0 is only crucial when running through the test suite, wherein several tests are expected to segfault, and will fail if ASan installs its own segfault handler.
|
||||
The `handle_segv=0` is only crucial when running through the test suite, wherein several tests are expected to segfault, and will fail if ASan installs its own segfault handler.
|
||||
|
||||
# Development #
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
## Bumping versions
|
||||
|
||||
Dart packages have two varieties of versioning schemes. We use
|
||||
[semver](semver.org) with a variation that the numbers are shifted to the right
|
||||
[semver](https://semver.org) with a variation that the numbers are shifted to the right
|
||||
if the package is not stable enough to reach a `1.0.0` release. Note that the
|
||||
Dart team culture was previously to keep packages at `0.x` for a long time,
|
||||
whereas now we prefer to publish `1.0.0` as soon as feasible to avoid confusion
|
||||
|
|
@ -113,11 +113,11 @@ at a time and then the old behavior can be removed once everything is migrated.
|
|||
request. Prefer to merge into that branch to resolve conflicts, prefer not
|
||||
to rebase.
|
||||
- Comments are tied to commits, so force pushing also destroys comment
|
||||
history in github prs.
|
||||
history in GitHub prs.
|
||||
- Pushing a new commit with code review updates makes it easy to review
|
||||
changes since your last review, by looking at the new commits only.
|
||||
- Add comments from the "Files changed" view, even as the PR author, so that
|
||||
they can sent in a batch rather than replying to each one by one on the
|
||||
"Conversation" view.
|
||||
- The [gh cli tool](https://cli.github.com/) makes it easy to checkout a PR
|
||||
in cases where a change may be easer to understand in an IDE.
|
||||
in cases where a change may be easier to understand in an IDE.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
---
|
||||
|
||||
Please file issues found in Dart using github issue tracking. However, please note that Dart is being developed in several github repos, so please make sure to file the issue in the correct repo. Consult the table below for details.
|
||||
Please file issues found in Dart using GitHub issue tracking. However, please note that Dart is being developed in several GitHub repos, so please make sure to file the issue in the correct repo. Consult the table below for details.
|
||||
|
||||
Component | Issue tracker
|
||||
--------- | -------------
|
||||
|
|
|
|||
|
|
@ -2,13 +2,13 @@
|
|||
|
||||
Flutter pinned packages are a set of packages that are pinned by the Flutter SDK to specific versions. Some examples are `package:characters` (pinned by `package:flutter`), `package:collection` (also pinned by `package:flutter`), and `package:path` (pinned by `package:flutter_test`).
|
||||
|
||||
To see the current list of pinned packages of the Flutter SDK at head, see the ‘dependencies’ section of the following pubspecs:
|
||||
To see the current list of pinned packages of the Flutter SDK at head, see the `dependencies` section of the following pubspecs:
|
||||
|
||||
- https://github.com/flutter/flutter/blob/master/packages/flutter/pubspec.yaml
|
||||
- https://github.com/flutter/flutter/blob/master/packages/flutter_test/pubspec.yaml
|
||||
- https://github.com/flutter/flutter/blob/master/packages/flutter_localizations/pubspec.yaml
|
||||
- https://github.com/flutter/flutter/blob/main/packages/flutter/pubspec.yaml
|
||||
- https://github.com/flutter/flutter/blob/main/packages/flutter_test/pubspec.yaml
|
||||
- https://github.com/flutter/flutter/blob/main/packages/flutter_localizations/pubspec.yaml
|
||||
|
||||
If you’re not using one of the above packages (e.g. `package:flutter_localizations`) then you won’t be affected by its package pinning.
|
||||
If you're not using one of the above packages (e.g. `package:flutter_localizations`) then you won't be affected by its package pinning.
|
||||
|
||||
## Why does Flutter pin package versions?
|
||||
|
||||
|
|
@ -16,34 +16,34 @@ By pinning its dependencies it is ensured the future release of a new package-ve
|
|||
|
||||
## How does the pinning affect me?
|
||||
|
||||
If you’re developing a Flutter app, your app can only use the specific version of a package that Flutter has pinned. If you have a direct dependency on a pinned package, your pubspec constraint must support the version pinned by Flutter. E.g. if Flutter has pinned `package:path` to `1.8.3`, your pubspec constraint must support that version:
|
||||
If you're developing a Flutter app, your app can only use the specific version of a package that Flutter has pinned. If you have a direct dependency on a pinned package, your pubspec constraint must support the version pinned by Flutter. E.g. if Flutter has pinned `package:path` to `1.8.3`, your pubspec constraint must support that version:
|
||||
|
||||
```yaml
|
||||
dependencies:
|
||||
path: ^1.8.0
|
||||
```
|
||||
|
||||
Similarly, if you’re using a package which itself has a dependency on a pinned package, that package needs to support the pinned version (i.e. your transitive dependencies also need to support the pinned version).
|
||||
Similarly, if you're using a package which itself has a dependency on a pinned package, that package needs to support the pinned version (i.e. your transitive dependencies also need to support the pinned version).
|
||||
|
||||
Generally people experience issues with pinning if their pubspec constraints don’t support the pinned Flutter version, or - transitively - if one of their package dependencies don’t support the pinned version.
|
||||
Generally people experience issues with pinning if their pubspec constraints don't support the pinned Flutter version, or - transitively - if one of their package dependencies don't support the pinned version.
|
||||
|
||||
## What are some workarounds?
|
||||
|
||||
### An immediate dependency doesn’t resolve
|
||||
### An immediate dependency doesn't resolve
|
||||
|
||||
Widen your constraint on the package in question (e.g. change a `>=1.7.0 < 1.8.0` constraint on package:path to `^1.8.0`).
|
||||
|
||||
### I see issues through one of my dependencies
|
||||
|
||||
The package you’re using needs to widen its constraint on the pinned package. Either you need to update your dependency to bring in a new version of the package, or, that package needs to publish a new version that supports the pinned package version. If a version of the package isn’t available which supports the pinned version, try visiting the issue tracker of the dependency to let them know about the issue.
|
||||
The package you're using needs to widen its constraint on the pinned package. Either you need to update your dependency to bring in a new version of the package, or, that package needs to publish a new version that supports the pinned package version. If a version of the package isn't available which supports the pinned version, try visiting the issue tracker of the dependency to let them know about the issue.
|
||||
|
||||
### I see issues through one of my dependencies but they can’t immediately release a new version
|
||||
### I see issues through one of my dependencies but they can't immediately release a new version
|
||||
|
||||
As a fallback solution, you can specify a [dependency override](https://dart.dev/tools/pub/dependencies#dependency-overrides) in your own pubspec. This will tell pub to use a specific version of a package whether or not it’s compatible with the other packages you’re using.
|
||||
As a fallback solution, you can specify a [dependency override](https://dart.dev/tools/pub/dependencies#dependency-overrides) in your own pubspec. This will tell pub to use a specific version of a package whether or not it's compatible with the other packages you're using.
|
||||
|
||||
```yaml
|
||||
dependency_overrides:
|
||||
foo: 1.8.3
|
||||
```
|
||||
|
||||
Note that you’re now consuming a version of ‘foo’ that not all of your other dependencies have been tested with; you may see analysis or runtime issues as a result (this should be considered a short-term solution).
|
||||
Note that you're now consuming a version of `foo` that not all of your other dependencies have been tested with; you may see analysis or runtime issues as a result (this should be considered a short-term solution).
|
||||
|
|
|
|||
|
|
@ -50,6 +50,6 @@ The commit message must contain the `[stable]` or `[beta]` hashtags to ensure re
|
|||
|
||||
The `Cherry-pick` footer must link to the original review on the main branch. Use the footer multiple times if multiple changes are bundled into the cherry-pick. If the change is original and isn't cherry-picked from main, then describe why the change is original. The purpose of the footer is to help reviewers understand the original change and know it is safe on the release branch.
|
||||
|
||||
The `Cherry-pick-request` footer must link to the github issue where the cherry-pick's rationale is being approved. The purpose of the footer is to help reviewers understand why the cherry-pick is needed and to ensure the approvals are obtained before submission.
|
||||
The `Cherry-pick-request` footer must link to the GitHub issue where the cherry-pick's rationale is being approved. The purpose of the footer is to help reviewers understand why the cherry-pick is needed and to ensure the approvals are obtained before submission.
|
||||
|
||||
The commit message must not contain the old `Reviewed-on`, `Reviewed-by`, and `Commit-Queue` footers from the old commit message as they are not true of the new change. The appropriate new footers will be automatically generated on submission.
|
||||
|
|
|
|||
|
|
@ -267,7 +267,7 @@ There are a few other miscellaneous labels you might run into:
|
|||
|
||||
|
||||
* **[merge-to-dev][]**, **[merge-to-stable][]**: These are used to track
|
||||
requests to cherry-pick a change from master to one of the [release
|
||||
requests to cherry-pick a change from main to one of the [release
|
||||
branches][branches].
|
||||
|
||||
* **[needs-info][]**: Like the name says, this means we need more
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
---
|
||||
|
||||
These instructions supplement https://dart.dev/get-dart with additional details for how to install beta and dev releases with brew (on MacOS), choco (on Windows), and apt-get (on Linux). Note that on all platforms you can also download SDK archives from all channels at https://dart.dev/tools/sdk/archive.
|
||||
These instructions supplement https://dart.dev/get-dart with additional details for how to install beta and dev releases with brew (on macOS), choco (on Windows), and apt-get (on Linux). Note that on all platforms you can also download SDK archives from all channels at https://dart.dev/tools/sdk/archive.
|
||||
|
||||
# Installing and upgrading on macOS with Homebrew
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Each of these outcomes has a canonical name. Things like:
|
|||
|
||||
There are other, more exotic outcomes. For the full list of them, see the code:
|
||||
|
||||
[pkg/status_file/lib/expectation.dart](https://github.com/dart-lang/sdk/blob/master/pkg/status_file/lib/expectation.dart)
|
||||
[`pkg/status_file/lib/expectation.dart`](https://github.com/dart-lang/sdk/blob/main/pkg/status_file/lib/expectation.dart)
|
||||
|
||||
In a perfect world, every test would pass in every configuration and the test
|
||||
runner could simplify verify that every test's outcome was "Pass". Alas, life is
|
||||
|
|
@ -97,7 +97,7 @@ entries are used. Otherwise, its entries are ignored.
|
|||
If there are entries in the implicit first headerless section, the condition is
|
||||
always considered to be true and the entries are always applied.
|
||||
|
||||
Arbitarily large expressions are supported, but the larger they are, the harder
|
||||
Arbitrarily large expressions are supported, but the larger they are, the harder
|
||||
it is for your fellow teammates to understand what outcomes are expected for a
|
||||
given configuration.
|
||||
|
||||
|
|
@ -147,11 +147,11 @@ There are a few different expression forms:
|
|||
to test against a literal value.
|
||||
|
||||
The set of variables that are available in status file expressions is baked
|
||||
into test.dart. You can see the full list of them here:
|
||||
into `test.dart`. You can see the full list of them here:
|
||||
|
||||
[tools/testing/dart/environment.dart](https://github.com/dart-lang/sdk/blob/master/tools/testing/dart/environment.dart#L13)
|
||||
[`tools/testing/dart/environment.dart`](https://github.com/dart-lang/sdk/blob/main/pkg/test_runner/lib/src/environment.dart#L12)
|
||||
|
||||
For each variable, test.dart also knows all of the values that are allowed
|
||||
For each variable, `test.dart` also knows all of the values that are allowed
|
||||
for it. It uses this to validate these expressions at parse time. If you
|
||||
misspell a variable, like `$compile` or test it against a value it can't
|
||||
have like `$runtime == dart2js` (dart2js is a compiler, not a runtime), it
|
||||
|
|
@ -256,10 +256,10 @@ async/multiple_timer_test: Pass, Fail # Timing related
|
|||
Many of these sections are disjoint so that if one applies, another won't, but
|
||||
not all of them are. For example, if you're running on Fuchsia on the VM with
|
||||
hot reload enabled, the second and last sections both apply. They have different
|
||||
expectations. So what does test.dart expect this test to do?
|
||||
expectations. So what does `test.dart` expect this test to do?
|
||||
|
||||
When there are multiple sets of expectations for the same file, test.dart unions
|
||||
all of the sets together. So, in this case, the resulting expectation is
|
||||
When there are multiple sets of expectations for the same file, `test.dart`
|
||||
unions all of the sets together. So, in this case, the resulting expectation is
|
||||
"RuntimeError, Pass, Fail".
|
||||
|
||||
A test succeeds if the outcome is *any* of the expectations. Here, that
|
||||
|
|
@ -276,8 +276,8 @@ Some "expectations" don't line up with actual possible test outcomes. Instead,
|
|||
they affect how the test runner works or have another purpose. A couple of
|
||||
important ones are:
|
||||
|
||||
* **Skip** and **SkipByDesign** – These tell test.dart to not run the test at
|
||||
all. The latter is OK, it means "this behavior isn't relevant for this
|
||||
* **Skip** and **SkipByDesign** – These tell `test.dart` to not run the test
|
||||
at all. The latter is OK, it means "this behavior isn't relevant for this
|
||||
configuration". For example, Dartium doesn't support "dart:io", so the
|
||||
status file says:
|
||||
|
||||
|
|
@ -302,4 +302,4 @@ important ones are:
|
|||
|
||||
There are some other special expectations, documented in the source here:
|
||||
|
||||
[/pkg/status_file/lib/expectation.dart](https://github.com/dart-lang/sdk/blob/master/pkg/status_file/lib/expectation.dart)
|
||||
[`/pkg/status_file/lib/expectation.dart`](https://github.com/dart-lang/sdk/blob/main/pkg/status_file/lib/expectation.dart)
|
||||
|
|
|
|||
|
|
@ -35,4 +35,4 @@ main() {
|
|||
|
||||
The full set of features is defined [here][features]. For any given configuration, the test runner knows which features that configuration supports. When it is determining which tests to run, if a test requires a feature that the configuration does not support, the test is automatically skipped.
|
||||
|
||||
[features]: https://github.com/dart-lang/sdk/blob/master/pkg/test_runner/lib/src/feature.dart
|
||||
[features]: https://github.com/dart-lang/sdk/blob/main/pkg/test_runner/lib/src/feature.dart
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Testing dart2js is complicated. There are a lot of configurations that are teste
|
|||
|
||||
* **VM Production/Developer mode:** this is the mode that Dart developers use to enable assertions and type checks while developing a Dart program. Since dart2js is a Dart program, the dart2js compiler engineers want to make sure that their assertions and type annotations are checked.
|
||||
|
||||
* **dart2js Production/Developer mode:** dart2js is an implementation of the Dart programming language. And just like the VM, dart2js should also support developer mode where assertions an type annotations are checked. So both production mode and developer mode of dart2js should be tested. Ideally, both in production mode and developer mode on the VM.
|
||||
* **dart2js Production/Developer mode:** dart2js is an implementation of the Dart programming language. And just like the VM, dart2js should also support developer mode where assertions and type annotations are checked. So both production mode and developer mode of dart2js should be tested. Ideally, both in production mode and developer mode on the VM.
|
||||
|
||||
Ideally, we would want to test all the entries in this matrix:
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ those out of the way first.
|
|||
|
||||
* **Bots**, **BuildBots**, **builders** - The infrastructure for automatically
|
||||
running the tests in the cloud across a number of configurations. Whenever a
|
||||
change lands on master, the bots run all of the tests to determine what
|
||||
change lands on main, the bots run all of the tests to determine what
|
||||
behavior changed.
|
||||
|
||||
## Expectations, outcomes, status files, and the results database
|
||||
|
|
@ -97,7 +97,7 @@ All this means that it's not as simple as "run test and if no errors then great,
|
|||
otherwise blow up." At a high level, what we really want is:
|
||||
|
||||
* To encode the behavior we *intend* to ship.
|
||||
* To know what behavior are *are* shipping.
|
||||
* To know what behavior *are* shipping.
|
||||
* To know when that behavior *changes* and what commits cause it.
|
||||
|
||||
### Expectation
|
||||
|
|
@ -249,7 +249,7 @@ test suites. For each test file:
|
|||
```
|
||||
|
||||
In other words, if the outcome and the expectation align, that's a "pass" in
|
||||
that the tool does what a human says its supposed to. If they disagree,
|
||||
that the tool does what a human says it's supposed to. If they disagree,
|
||||
there is some kind of "failure"—either an error was supposed to
|
||||
reported and wasn't, or an unexpected error occurred.
|
||||
|
||||
|
|
@ -418,7 +418,7 @@ also survive a gauntlet of robots.
|
|||
The commit queue is a system that automatically runs your not-yet-landed change
|
||||
on a subset of all of the bots. This subset is the trybots. They run a selected
|
||||
set of configurations to balance good coverage against completing in a timely
|
||||
manner. If all of those tests pass the change can land on master. Here "pass"
|
||||
manner. If all of those tests pass the change can land on main. Here "pass"
|
||||
means that the test result is *the same as it was before your change.* A
|
||||
*change* in status is what's considered "failure".
|
||||
|
||||
|
|
@ -430,7 +430,7 @@ deliberate and desired.
|
|||
This workflow is still in flux as part of the move away from status files.
|
||||
**TODO: Rewrite or remove this once the approval workflow is gone or complete.**
|
||||
|
||||
Once you please all of the trybots, the change can land on master. After that
|
||||
Once you please all of the trybots, the change can land on main. After that
|
||||
*all* of the bots pick up the change and run the tests on all of the supported
|
||||
configurations against your change. Assuming we've picked a good set of trybots,
|
||||
these should all pass. But sometimes you encounter a test that behaves as
|
||||
|
|
@ -477,8 +477,8 @@ single Dart file][expect lib] that exposes a rudimentary JUnit-like API for
|
|||
making assertions about behavior. Fortunately, since the behavior we're testing
|
||||
is also pretty low-level, that API is usually sufficient.
|
||||
|
||||
[expect pkg]: https://github.com/dart-lang/sdk/tree/master/pkg/expect
|
||||
[expect lib]: https://github.com/dart-lang/sdk/blob/master/pkg/expect/lib/expect.dart
|
||||
[expect pkg]: https://github.com/dart-lang/sdk/tree/main/pkg/expect
|
||||
[expect lib]: https://github.com/dart-lang/sdk/blob/main/pkg/expect/lib/expect.dart
|
||||
|
||||
The way it works is that if an assertion fails, it throws an exception. That
|
||||
exception unwinds the entire callstack and a Dart implementation then exits in
|
||||
|
|
@ -489,7 +489,7 @@ If you are writing asynchronous tests, there is a separate tiny
|
|||
["async_helper"][async pkg] package that talks to the test runner to ensure all
|
||||
asynchronous operations performed by the test have a chance to complete.
|
||||
|
||||
[async pkg]: https://github.com/dart-lang/sdk/tree/master/pkg/async_helper
|
||||
[async pkg]: https://github.com/dart-lang/sdk/tree/main/pkg/async_helper
|
||||
|
||||
With these two packages, it's straightforward to write tests of expected correct
|
||||
runtime behavior. You can also write tests for validating runtime *failures* by
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@
|
|||
|
||||
**Version**: 0.2
|
||||
|
||||
We have created a _Dart specification parser_, built on a grammar specification [Dart.g](https://github.com/dart-lang/sdk/blob/master/tools/spec_parser/Dart.g), which is transformed into a working parser by the tool [ANTLR](https://www.antlr.org/index.html), using a couple of helper files (in particular, [spec_parse.py](https://github.com/dart-lang/sdk/blob/master/tools/spec_parse.py) and [spec_parser](https://github.com/dart-lang/sdk/tree/master/tools/spec_parser)). This document gives a short introduction to what it is, and some motivations for why we have it, along with an outline of the consequences for the testing workflow when we have a specification parser.
|
||||
We have created a _Dart specification parser_, built on a grammar specification [Dart.g](https://github.com/dart-lang/sdk/blob/main/tools/spec_parser/Dart.g), which is transformed into a working parser by the tool [ANTLR](https://www.antlr.org/index.html), using a couple of helper files (in particular, [spec_parse.py](https://github.com/dart-lang/sdk/blob/main/tools/spec_parse.py) and [spec_parser](https://github.com/dart-lang/sdk/tree/main/tools/spec_parser)). This document gives a short introduction to what it is, and some motivations for why we have it, along with an outline of the consequences for the testing workflow when we have a specification parser.
|
||||
|
||||
## Motivation
|
||||
|
||||
One main **motivation** for having this specification parser is that we can use it to parse existing Dart source code. This allows us to verify that `Dart.g` **specifies the syntax** in a manner which is consistent and parseable, and which corresponds precisely to the language as it is **actually implemented** and used.
|
||||
|
||||
The other main **motivation** is that `Dart.g` is a mechanized and hence precise specification of the language syntax. This allows us to use `Dart.g` as a source of information about how to maintain the grammar rules in the [language specification](https://github.com/dart-lang/language/blob/master/specification/dartLangSpec.tex). The grammar rules in the language specification will never be a verbatim copy of the ones in `Dart.g`, because that is an ANTLR specification which necessarily contains a number of details that are specific to ANTLR, or otherwise accidental. However, `Dart.g` is still such a detailed source of trustworthy information that we expect it to be very **helpful in the maintenance of** the language **specification** grammar rules.
|
||||
The other main **motivation** is that `Dart.g` is a mechanized and hence precise specification of the language syntax. This allows us to use `Dart.g` as a source of information about how to maintain the grammar rules in the [language specification](https://github.com/dart-lang/language/blob/main/specification/dartLangSpec.tex). The grammar rules in the language specification will never be a verbatim copy of the ones in `Dart.g`, because that is an ANTLR specification which necessarily contains a number of details that are specific to ANTLR, or otherwise accidental. However, `Dart.g` is still such a detailed source of trustworthy information that we expect it to be very **helpful in the maintenance of** the language **specification** grammar rules.
|
||||
|
||||
The grammar rules in the **language specification** should be **more abstract** than the ones in `Dart.g`. It is not even a problem if the grammar rules in the language specification are somewhat ambiguous, especially if this allows them to be significantly simpler and more readable. One justification for this is that grammar rules in a language specification may well be used for mentally constructing expressions, declarations, or other constructs, when the reader is thinking about how the language can be used to express a specific idea as software.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Suggested ideas for code samples include:
|
|||
* A minimal Dart library that can parse something simple.
|
||||
(Perhaps a miniscule subset of YAML).
|
||||
* A minimal Dart console program that can print the size and filename of the
|
||||
first file in a USTAR tar archieve (ignoring other tar extensions).
|
||||
first file in a USTAR tar archive (ignoring other tar extensions).
|
||||
* Check out the _getting started_ section for each idea, invent your own small demo,
|
||||
or ask the potential mentor.
|
||||
|
||||
|
|
@ -177,12 +177,12 @@ able to read all packages on [pub.dev](https://pub.dev).
|
|||
|
||||
**Getting Started**
|
||||
Try writing a small sample program that can print the file name and size of the
|
||||
first file in a USTAR tar archieve. Link to the sample in a secret gist attached
|
||||
first file in a USTAR tar archive. Link to the sample in a secret gist attached
|
||||
to the project proposal. For the proposal, it would be valuable to include:
|
||||
* References to relevant documentation of the various TAR formats.
|
||||
* An API outline for the streaming TAR reader package.
|
||||
(Explain how an program using the package would read a tar file).
|
||||
* List of TAR features you'd suggest supporting: what are the strech goals,
|
||||
(Explain how a program using the package would read a tar file).
|
||||
* List of TAR features you'd suggest supporting: what are the stretch goals,
|
||||
what features do we ignore, how do we expose these features.
|
||||
(From the perspective of `pub` we mostly care about ordinary files and folders).
|
||||
* How do we plan to test this? What test cases can we find? How can we become
|
||||
|
|
@ -205,7 +205,7 @@ Stretch goal might be to handle `LICENSE` files with multiple licenses and
|
|||
display an SPDX license expression on pub.dev.
|
||||
|
||||
**Getting Started**
|
||||
Try writing a small sample program that can fetch one of the [SPDX master files](https://github.com/spdx/license-list-XML/tree/master/src) and print it to terminal as
|
||||
Try writing a small sample program that can fetch one of the [SPDX origin files](https://github.com/spdx/license-list-XML/tree/main/src) and print it to terminal as
|
||||
markdown. Don't make it too perfect, just figure out how to parse the XML.
|
||||
For the proposal, it would be valuable to include:
|
||||
* References to relevant documentation.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ All projects assume familiarity with Dart (and sometimes Flutter). Aspiring appl
|
|||
Applicants are welcome to find and fix bugs in [Dart](https://github.com/dart-lang/sdk) or some of the [packages written by the Dart team](https://pub.dev/publishers/dart.dev/packages). However, getting reviews can take a long time as code owners may be busy working on new features. So instead of requiring applicants to fix a _good first bug_, we
|
||||
suggest that applicants write a working code sample relevant for the proposed project.
|
||||
|
||||
The code sample can be attached to the application as a [gist](https://gist.github.com/), or simply github repository. Suggested ideas below includes proposed "Good Sample Projects".
|
||||
The code sample can be attached to the application as a [gist](https://gist.github.com/), or simply GitHub repository. Suggested ideas below includes proposed "Good Sample Projects".
|
||||
|
||||
**Do not spend too much energy on this piece of sample code**, we just want to see
|
||||
that you can code something relevant -- and that this sample code can run and do something non-trivial. Be aware that we have a limited number of
|
||||
|
|
@ -103,7 +103,7 @@ Stretch goal might be to handle `LICENSE` files with multiple licenses and
|
|||
display an SPDX license expression on pub.dev.
|
||||
|
||||
**Getting Started**
|
||||
Try writing a small sample program that can fetch one of the [SPDX master files](https://github.com/spdx/license-list-XML/tree/master/src) and print it to terminal as
|
||||
Try writing a small sample program that can fetch one of the [SPDX origin files](https://github.com/spdx/license-list-XML/tree/main/src) and print it to terminal as
|
||||
markdown. Don't make it too perfect, just figure out how to parse the XML.
|
||||
For the proposal, it would be valuable to include:
|
||||
* Comparison of text similarity approach to SPDX matching guidelines,
|
||||
|
|
@ -127,7 +127,7 @@ For the proposal, it would be valuable to include:
|
|||
**Description**:
|
||||
With `dart:ffi` binding to native libraries we have an opportunity to build more performant and more feature rich IO libraries than `dart:io`.
|
||||
Building such libraries has become one step easier by [`package:ffigen`](https://pub.dev/packages/ffigen) which can generate the bindings for the native libraries.
|
||||
In this project we would like to target HTTP by binding to Cronet's [native API](https://chromium.googlesource.com/chromium/src/+/master/components/cronet/native/test_instructions.md).
|
||||
In this project we would like to target HTTP by binding to Cronet's [native API](https://chromium.googlesource.com/chromium/src/+/main/components/cronet/native/test_instructions.md).
|
||||
|
||||
This project will be challenging.
|
||||
It requires the whole `dart:ffi` toolbox. For example: native resource management with finalizers and asynchronous callbacks with native ports.
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ For GSoC related discussions please use the [dart-gsoc group](https://groups.goo
|
|||
**Potential mentors**
|
||||
* Jonas Jensen ([jonasfj](https://github.com/jonasfj)) `jonasfj@google.com`
|
||||
* Daco Harkes ([dcharkes](https://github.com/dcharkes)) `dacoharkes@google.com`
|
||||
* Sighurd Meldgaard ([sigurdm](https://github.com/sigurdm)) `sigurdm@google.com`
|
||||
* Liam Appelbe ([liamappelbe](https://github.com/liamappelbe)) `liama@google.com`
|
||||
* Sigurd Meldgaard ([sigurdm](https://github.com/sigurdm)) `sigurdm@google.com`
|
||||
* Liam Appelbe ([liamappelbe](https://github.com/liamappelbe)) `liama@google.com`
|
||||
* Majid Hajian ([mhadaily](https://github.com/mhadaily))
|
||||
* Simon Lightfoot ([slightfoot](https://github.com/slightfoot))
|
||||
* Miguel Beltran ([miquelbeltran](https://github.com/miquelbeltran))
|
||||
|
|
@ -99,7 +99,7 @@ changelogs and successfully parse the vast majority of changelogs on pub.dev.
|
|||
- **Skills**: Dart, Flutter
|
||||
|
||||
**Description**:
|
||||
The Flutter Community (FC) is providing several packages to the community and pub. dev that is all maintained differently. It’s hard for Flutter Community admins to engage with all of the changes, releases, changelogs, and activities on all packages.
|
||||
The Flutter Community (FC) is providing several packages to the community and pub. dev that is all maintained differently. It's hard for Flutter Community admins to engage with all of the changes, releases, changelogs, and activities on all packages.
|
||||
|
||||
One of the main challenges is keeping track of releases, especially allowing maintainers to trigger package releases on pub dev without giving them super admin access.
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ Last but not least, it would be great to make the dashboard even smarter by addi
|
|||
|
||||
Tasks:
|
||||
|
||||
* [ ] Simple login with Github only
|
||||
* [ ] Simple login with GitHub only
|
||||
* [ ] Gather information and show them as graphs, numbers and etc. to give a better understanding of the overall performance of the organization
|
||||
* [ ] Details of each repo under the orgs, such as number of issues, in active issues, closing and maintainers
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ code sample in documentation comments:
|
|||
|
||||
Some of these questions might be debated in the project proposal.
|
||||
A project proposal should also discuss how package authors would run the code sample tests.
|
||||
Finally, a project proposal is encouraged to outline implementation stages, including strech goals.
|
||||
Finally, a project proposal is encouraged to outline implementation stages, including stretch goals.
|
||||
|
||||
|
||||
**Good Sample Project**: Create a function that given some Dart code will use `package:analyzer` to do static analysis of the code and count static errors. Additional step would be to try and use `package:analyzer` to extract documentation comments from source code and use `package:markdown` to extract code-snippets from source code comments, and then run analysis on the extracted source code snippets. Ideally, all of this could be done, in-memory without writing files to disk.
|
||||
|
|
@ -121,7 +121,7 @@ Successfully completely this project will likely involve:
|
|||
* Creating a JNI bindings for those APIs using [`package:jnigen`](https://pub.dev/packages/jnigen).
|
||||
* Creating a higher-level interface over the JNI bindings e.g. so the Dart developer can work with [Dart URIs](https://api.dart.dev/stable/dart-core/Uri-class.html) rather than [java.net.URI](https://developer.android.com/reference/java/net/URI).
|
||||
* Creating a [`package:http` `Client`](https://pub.dev/documentation/http/latest/http/Client-class.html) implementation using the interface above.
|
||||
* Verifying that the `Client` implementation passes the [conformance tests](https://github.com/dart-lang/http/tree/master/pkgs/http_client_conformance_tests).
|
||||
* Verifying that the `Client` implementation passes the [conformance tests](https://github.com/dart-lang/http/tree/main/pkgs/http_client_conformance_tests).
|
||||
|
||||
You'll like working on this project because:
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ You'll like working on this project because:
|
|||
* There are existing [conformance tests](https://github.com/dart-lang/http/tree/master/pkgs/http_client_conformance_tests) to validate the correctness of the work.
|
||||
* Dart users want it!
|
||||
|
||||
A good project proposal will describe what Java APIs are necessary to implement the [`package:http` `Client` interface](https://pub.dev/documentation/http/latest/http/Client-class.html) and an *excellent* project proposal will discuss what features [`package:jnigen`](https://pub.dev/packages/jnigen) needs to to use those APIs from Dart.
|
||||
A good project proposal will describe what Java APIs are necessary to implement the [`package:http` `Client` interface](https://pub.dev/documentation/http/latest/http/Client-class.html) and an *excellent* project proposal will discuss what features [`package:jnigen`](https://pub.dev/packages/jnigen) needs to use those APIs from Dart.
|
||||
|
||||
**Good Sample Project**: Try writing a small [Flutter](https://flutter.dev/) application that makes HTTP requests using Java API bindings created with [`package:jnigen`](https://pub.dev/packages/jnigen).
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ We would like to explore the possibilities of the new language features that cou
|
|||
We are using [Federated plugins](https://docs.flutter.dev/development/packages-and-plugins/developing-packages#federated-plugins) therefore this is likely to involve:
|
||||
|
||||
* refactoring `platform_interface` class for each package,
|
||||
* refactoring app-faceing and platform-specific-implementation packages,
|
||||
* refactoring app-facing and platform-specific-implementation packages,
|
||||
* potentially removing native code and replacing it with direct dart API calls,
|
||||
* rewriting the entire package unit and e-2-e tests,
|
||||
* replacing CI/CD existing workflow making it compatible with upcoming language feature, and
|
||||
|
|
@ -157,7 +157,7 @@ We are using [Federated plugins](https://docs.flutter.dev/development/packages-a
|
|||
|
||||
Some of these questions might be debated in the project proposal. A project proposal is encouraged to outline implementation stages, including stretch goals.
|
||||
|
||||
**Good Sample Project**: Create new packages for both [Device_Info](https://github.com/fluttercommunity/plus_plugins/tree/main/packages/device_info_plus) or [Connectivity_Plus](https://github.com/fluttercommunity/plus_plugins/tree/main/packages/connectivity_plus) and redesign part of the APIs including in platform interface and use Dart 3 language features, then create a Flutter project from Master branch and then use these packages with latest Flutter and Dart 3 version that uses all APIs.
|
||||
**Good Sample Project**: Create new packages for both [Device_Info](https://github.com/fluttercommunity/plus_plugins/tree/main/packages/device_info_plus) or [Connectivity_Plus](https://github.com/fluttercommunity/plus_plugins/tree/main/packages/connectivity_plus) and redesign part of the APIs including in platform interface and use Dart 3 language features, then create a Flutter project from main branch and then use these packages with latest Flutter and Dart 3 version that uses all APIs.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -238,7 +238,7 @@ code sample in documentation comments:
|
|||
|
||||
Some of these questions might be debated in the project proposal.
|
||||
A project proposal should also discuss how package authors would run the code sample tests.
|
||||
Finally, a project proposal is encouraged to outline implementation stages, including strech goals.
|
||||
Finally, a project proposal is encouraged to outline implementation stages, including stretch goals.
|
||||
|
||||
**Good Sample Project**: Create a function that given some Dart code will use `package:analyzer` to do static analysis of the code and count static errors. Additional step would be to try and use `package:analyzer` to extract documentation comments from source code and use `package:markdown` to extract code-snippets from source code comments, and then run analysis on the extracted source code snippets. Ideally, all of this could be done, in-memory without writing files to disk.
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ to a change being released in a dev channel release.
|
|||
|
||||
* Very short summary of the intended change
|
||||
|
||||
* Link to the above mentioned issue
|
||||
* Link to the above-mentioned issue
|
||||
|
||||
* A request that developers may leave comments in the linked issue, if this
|
||||
breaking change poses a severe problem.
|
||||
|
|
@ -136,8 +136,8 @@ After the breaking change has been made, the person who made the change must:
|
|||
* Reply to the original announcement email, and make a note that the change is
|
||||
being implemented.
|
||||
|
||||
If not approved, or if the requestor decides to not pursue the change, the
|
||||
requestor must:
|
||||
If not approved, or if the requester decides to not pursue the change, the
|
||||
requester must:
|
||||
|
||||
* Reply to the original announcement email, and make a note that the change is
|
||||
has been rejected, with a quick summary of the rationale for that.
|
||||
|
|
|
|||
Loading…
Reference in a new issue