chore(docs): bump references to docker image versions upon release of 5.0.0 (#33872)

docs/docs/installation/docker-builds.mdx

@@ -16,7 +16,7 @@ https://hub.docker.com/r/apache/superset) using GitHub Actions.
 Different sets of images are built and/or published at different times:
 
 - **Published releases** (`release`): published using
-  tags like `3.0.0` and the `latest` tag.
+  tags like `5.0.0` and the `latest` tag.
 - **Pull request iterations** (`pull_request`): for each pull request, while
   we actively build the docker to validate the build, we do
   not publish those images for security reasons, we simply `docker build --load`
@@ -32,7 +32,7 @@ for the build, and/or base image.
 Here are the build presets that are exposed through the `supersetbot docker` utility:
 
 - `lean`: The default Docker image, including both frontend and backend. Tags
-  without a build_preset are lean builds (ie: `latest`, `4.0.0`, `3.0.0`, ...). `lean`
+  without a build_preset are lean builds (ie: `latest`, `5.0.0`, `4.1.2`, ...). `lean`
   builds do not contain database
   drivers, meaning you need to install your own. That applies to analytics databases **AND
   the metadata database**. You'll likely want to layer either `mysqlclient` or `psycopg2-binary`
@@ -73,10 +73,10 @@ Here's an example Dockerfile that does this. Follow the in-line comments to cust
 your desired Superset version and database drivers. The comments also note that a certain feature flag will
 have to be enabled in your config file.
 
-You would build the image with `docker build -t mysuperset:latest .` or `docker build -t ourcompanysuperset:4.1.2 .`
+You would build the image with `docker build -t mysuperset:latest .` or `docker build -t ourcompanysuperset:5.0.0 .`
 
 ```Dockerfile
-# change this to apache/superset:4.1.2 or whatever version you want to build from;
+# change this to apache/superset:5.0.0 or whatever version you want to build from;
 # otherwise the default is the latest commit on GitHub master branch
 FROM apache/superset:master
 
@@ -86,7 +86,7 @@ USER root
 ENV PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/playwright-browsers
 
 # Install packages using uv into the virtual environment
-# Superset started using uv after the 4.1 branch; if you are building from apache/superset:4.1.x,
+# Superset started using uv after the 4.1 branch; if you are building from apache/superset:4.1.x or an older version,
 # replace the first two lines with RUN pip install \
 RUN . /app/.venv/bin/activate && \
     uv pip install \

docs/docs/installation/docker-compose.mdx

@@ -36,12 +36,12 @@ Note that there are 3 major ways we support to run `docker compose`:
   at the time you fire this up will be reflected, but changes to the code
   while `up` won't be reflected in the app
 1. **compose-image-tag.yml** where we fetch an image from docker-hub say for the
-  `3.0.0` release for instance, and fire it up so you can try it. Here what's in
+  `5.0.0` release for instance, and fire it up so you can try it. Here what's in
   the local branch has no effects on what's running, we just fetch and run
   pre-built images from docker-hub. For `docker compose` to work along with the
   Postgres image it boots up, you'll want to point to a `-dev`-suffixed TAG, as in
-  `export TAG=4.0.0-dev` or `export TAG=3.0.0-dev`, with `latest-dev` being the default.
-  That's because The `dev` builds happen to package the `psycopg2-binary` required to connect
+  `export TAG=5.0.0-dev` or `export TAG=4.1.2-dev`, with `latest-dev` being the default.
+  The `dev` builds include the `psycopg2-binary` required to connect
   to the Postgres database launched as part of the `docker compose` builds.
 
 More on these two approaches after setting up the requirements for either.
@@ -113,7 +113,7 @@ docker compose -f compose-non-dev.yml up
 
 ```bash
 # Set the version you want to run
-export TAG=3.1.1
+export TAG=5.0.0
 # Fetch the tag you're about to check out (assuming you shallow-cloned the repo)
 git fetch --depth=1 origin tag $TAG
 # Could also fetch all tags too if you've got bandwidth to spare
@@ -129,8 +129,8 @@ Refer to the docker-related documentation to learn more about existing tags you
 from Docker Hub.
 
 :::note
-For option #2 and #3, we recommend checking out the release tag from the better repository
-(ie: `git checkout 4.0.0`) for more guaranteed results. This ensures that the `docker-compose.*.yml`
+For option #2 and #3, we recommend checking out the release tag from the git repository
+(ie: `git checkout 5.0.0`) for more guaranteed results. This ensures that the `docker-compose.*.yml`
 configurations and that the mounted `docker/` scripts are in sync with the image you are
 looking to fire up.
 :::
@@ -143,7 +143,7 @@ its metadata database. In production, this database should be backed up.  The de
 with docker compose will store that data in a PostgreSQL database contained in a Docker
 [volume](https://docs.docker.com/storage/volumes/), which is not backed up.
 
-Again, **DO NOT USE THIS FOR PRODUCTION**
+Again, **THE DOCKER-COMPOSE INSTALLATION IS NOT PRODUCTION-READY OUT OF THE BOX.**
 
 :::
 

docs/docs/quickstart.mdx

@@ -32,7 +32,7 @@ git clone https://github.com/apache/superset
 $ cd superset
 
 # Set the repo to the state associated with the latest official version
-$ git checkout tags/4.1.2
+$ git checkout tags/5.0.0
 
 # Fire up Superset using Docker Compose
 $ docker compose -f compose-image-tag.yml up