Baixar DDEV 1.25.4 per a Windows

## Installation

See the [installation instructions](https://docs.ddev.com/en/stable/users/install/ddev-installation/) for details, but it's easy:

• macOS：`brew install ddev/ddev/ddev` or just `brew upgrade ddev`.
• Linux：Use `sudo apt-get update && sudo apt-get install ddev`, see [apt/yum installation](https://docs.ddev.com/en/stable/users/install/ddev-installation/#linux)
⚠️ **Linux apt/yum users**：packages are now served from Cloudsmith (`packages.ddev.com`). Your existing Gemfury (`pkg.ddev.com`) setup keeps working, but please re-run the [Linux installation steps](https://docs.ddev.com/en/stable/users/install/ddev-installation/#ddev-installation-linux) to switch over.
• Windows and WSL2：Download the [Windows Installer](https://ddev.com/download/); you can run it for install or upgrade.
⚠️ **Traditional Windows users (not WSL2)**：If needed, the installer will prompt you to uninstall the previous system-wide installation to avoid conflicts with the new per-user installation.
• Consider `ddev delete images` or `ddev delete images --all` after upgrading to free up disk space used by previous Docker image versions. This does no harm.
• Consider `ddev config --auto` to update your projects to current configuration.

## Highlights

• **Database seeding and reset:** `ddev start --seed-snapshot=<name-or-path>` fills a new database from any snapshot, and `ddev start --reset-database` deletes the current database and starts fresh, see **Snapshots and Database Seeding** below
• **MySQL 9.7 LTS support**, and MySQL 8.0/8.4 now build from [Docker Hardened Images](https://hub.docker.com/hardened-images/catalog/dhi/mysql/images) (`dhi.io/mysql`) instead of `bitnamilegacy/mysql`, which gets no updates
• **Env files:** `.env.local` for values you don't want in Git, several files per service separated by a label, and global files that apply to every project, see [Environment Variables](https://docs.ddev.com/en/stable/users/configuration/environment-variables/)
• **Set things once for every project:** global Dockerfiles in `~/.ddev/web-build/` and `~/.ddev/db-build/`, and global env files in `~/.ddev/.env*`, see **Global Configuration** below
• **apt/rpm packages are now published to Cloudsmith** (`packages.ddev.com`) as well as Gemfury, and the yum repo now verifies package signatures, which the Gemfury one never did. Gemfury (`pkg.ddev.com`) is still supported but will be retired eventually; see the Linux note above to switch over

## Snapshots and Database Seeding

• A snapshot named `seed` is automatically loaded when you start a project with an empty database. So if you delete your db or project and then `ddev start`, you'll have the database from the `seed` snapshot.
• [`ddev start --seed-snapshot`](https://docs.ddev.com/en/stable/users/usage/database-management/#seeding-a-fresh-database-from-a-snapshot) fills a new database from a snapshot in `.ddev/db_snapshots`, or from a path to one anywhere else on your machine. A snapshot outside the project is read where it is instead of being copied, so a multi-GB file is not duplicated. A snapshot named `seed` is used automatically, with no flag. Works for MariaDB, MySQL, and PostgreSQL
• [`ddev start --reset-database`](https://docs.ddev.com/en/stable/users/usage/database-management/#starting-over-with-a-new-database) deletes the database and starts fresh. It takes a snapshot first, using the database version that created the data, so this also works when you already changed `database:` in your config. `ddev config --database=` now warns instead of failing, and `ddev delete` no longer refuses to work on a project whose data came from a different database server
• `ddev snapshot restore --force` restores a snapshot made by a different version of the same database server
• `ddev snapshot --list` shows each snapshot's size and database version
• `ddev snapshot restore` and `ddev snapshot --list` also see snapshots from other Git worktrees of the same repository, so a database doesn't have to be copied between worktrees by hand
• Snapshots and the database seed can skip compression with `--uncompressed`：more disk space, faster restore. The `base_db` seed also reads zstd now, not only gzip, which is much faster for a custom `dbimage` with a large database built into it, thanks to @weitzman

## Global Configuration

These apply to every project on your machine, so you set them once instead of in each project.

• New [global Dockerfiles](https://docs.ddev.com/en/stable/users/extend/customizing-images/#global-dockerfiles) in `~/.ddev/web-build/` and `~/.ddev/db-build/` add the same image changes to every project - CA certificates, system tools, extra apt packages. If a project has a file with the same name in its own `.ddev/web-build/`, the project file is used, thanks to @rmott-littler
• New [global env files](https://docs.ddev.com/en/stable/users/configuration/environment-variables/#global-env-files) `~/.ddev/.env` and `~/.ddev/.env.<service>` set variables for every project. This is the only way to set a variable globally for a container other than `web`, since `web_environment` only reaches `web`. If a project sets the same variable, the project value is used. Write these files with [`ddev dotenv global set`](https://docs.ddev.com/en/stable/users/usage/commands/#dotenv-global-set)
• Add-on install actions now see `.ddev/.env` and the global `~/.ddev/.env*` files, not only `.ddev/.env.<addon>`. If you set a `DDEV_*` variable in `.ddev/.env`, that value is used there. A `.ddev/.env.<service>.<label>` file is also passed into that service's container now; before, it was only used to fill in variables in your docker-compose files

## Features

• **Two new project types:** [MODX Revolution](https://docs.ddev.com/en/stable/users/quickstart/#modx-revolution) 2.x/3.x, thanks to @casparml, and [Maho](https://docs.ddev.com/en/stable/users/quickstart/#maho), thanks to @fballiano
• Shopware 6 projects get `shopware-cli` in the web image, plus `ddev admin-watch` and `ddev storefront-watch` with the ports they need, so the [ddev-shopware-cli](https://github.com/vanWittlaer/ddev-shopware-cli) add-on isn't needed, thanks to @vanWittlaer
• New [`ddev add-on update`](https://docs.ddev.com/en/stable/users/usage/commands/#add-on-update) checks installed add-ons against their latest GitHub release and updates the outdated ones, with `--dry-run` to see what would change
• New [`ddev utility download-ddev`](https://docs.ddev.com/en/stable/users/usage/commands/#utility-download-ddev) fetches the `ddev` and `ddev-hostname` binaries for a PR, branch, commit, release tag, latest stable, or `main` HEAD, without touching your installed DDEV
• New [`ddev utility delete-volume`](https://docs.ddev.com/en/stable/users/usage/commands/#utility-delete-volume) removes one of the project's Docker volumes by name or from an interactive list, for add-ons like ddev-solr that create their own
• [`ddev launch --print-url`](https://docs.ddev.com/en/stable/users/usage/commands/#launch) and `DDEV_LAUNCH_PRINT_URL=true ddev launch` print the URL instead of opening a browser, for SSH, containers, and CI, thanks to @steffenmaechtel
• New [`ddev tablepro`](https://docs.ddev.com/en/stable/users/usage/commands/#tablepro) host command for the TablePro database client on macOS, thanks to @datlechin
• New [`nodejs_root`](https://docs.ddev.com/en/stable/users/configuration/config/#nodejs_root) lets `nodejs_version：auto`/`engine` read the version file from a subdirectory such as `web/themes/custom/mytheme`. Both now require that file to exist; before, if it was missing, DDEV installed its default version without telling you, thanks to @dpacassi
• The [`dbimage`](https://docs.ddev.com/en/stable/users/configuration/config/#dbimage) config option works again after a long absence, mirroring `webimage`, along with `ddev config --db-image`/`--db-image-default`
• If you pin a custom `webimage` or `dbimage`, `ddev start` warns you when that image was built from an older DDEV image than this version expects, instead of failing later in a way that gives no hint why. Official images now record the DDEV version they were built for, so the warning starts working after you rebuild your own image, thanks to @weitzman
• `ddev ssh` and `ddev exec` pass your `TERM` and `COLORTERM` into interactive sessions, so you get more than 16 colors, thanks to @wazum
• `ddev start` warns when DDEV itself is an unreleased build from a PR or a local branch, and `ddev version` shows where it came from
• Drupal `settings.ddev.php` configures `symfony_mailer_lite` the way it already configured `symfony_mailer`, thanks to @mxr576
• The [FAQ](https://docs.ddev.com/en/stable/users/usage/faq/#homebrew) explains how to move from Homebrew to a specific DDEV version, thanks to @joachim-n

## Bug Fixes for Regressions from v1.25.3

• Project image builds are fast again. Permissions on the Node.js directory were being changed recursively on every build, and now they are set once when the image is built
• Add-ons and apps that write log files straight into `/var/log` can do that again, after the directory was locked down to root only
• A site that generates `/robots.txt` itself works again, including Drupal's RobotsTxt module. An nginx rule was answering `/robots.txt` before your site could, and it is now removed
• Projects that pin the web service to a specific platform, like `platform：linux/amd64` on an Apple Silicon Mac, start again
• Orphan containers get removed again, so Docker Compose stops warning about them

## Bug Fixes

• `ddev wp` uses the path from your project's own `wp-cli.yml` again, and only falls back to the docroot when that file doesn't set one, which is what the docs always said. Since v1.24.5 it always added `--path=$DDEV_DOCROOT`, which broke Bedrock and any layout where WordPress isn't in the docroot
• Running `ddev` in a subdirectory that has its own `.ddev/config.yaml`, like a