Documentation should not mention deprecated version declaration

docs/how-tos/automatically-prune-old-backups.md

@@ -14,8 +14,6 @@ Be aware that this mechanism looks at __all files in the target bucket or archiv
 In case you need to use a target that cannot be used exclusively for your backups, you can configure `BACKUP_PRUNING_PREFIX` to limit which files are considered eligible for deletion:
 
 ```yml
-version: '3'
-
 services:
   # ... define other services using the `data` volume here
   backup:

docs/how-tos/handle-file-uploads-using-third-party-tools.md

@@ -20,8 +20,6 @@ RUN apk add rsync
 Using this image, you can now omit configuring any of the supported storage backends, and instead define your own mechanism in a `docker-volume-backup.copy-post` label:
 
 ```yml
-version: '3'
-
 services:
   backup:
     image: your-custom-image

docs/how-tos/replace-deprecated-backup-from-snapshot.md

@@ -11,8 +11,6 @@ Starting with version 2.15.0, the `BACKUP_FROM_SNAPSHOT` feature has been deprec
 If you need to prepare your sources before the backup is taken, use `archive-pre`, `archive-post` and an intermediate volume:
 
 ```yml
-version: '3'
-
 services:
   my_app:
     build: .

docs/how-tos/run-custom-commands.md

@@ -28,8 +28,6 @@ the `docker-volume-backup` container as shown in the Quickstart example.
 Taking a database dump using `mysqldump` would look like this:
 
 ```yml
-version: '3'
-
 services:
   # ... define other services using the `data` volume here
   database:
@@ -56,8 +54,6 @@ In case you use `EXEC_LABEL` together with configuration mounted from `conf.d` i
 Else, schedules that do not specify an `EXEC_LABEL` will still trigger commands on all containers with such labels, no matter whether they specify `docker-volume-backup.exec-label` or not.
 
 ```yml
-version: '3'
-
 services:
   database:
     image: mariadb
@@ -87,8 +83,6 @@ By default the backup command is executed by the user provided by the container'
 It is possible to specify a custom user that is used to run commands in dedicated labels with the format `docker-volume-backup.[step]-[pre|post].user`:
 
 ```yml
-version: '3'
-
 services:
   gitea:
     image: gitea/gitea

docs/how-tos/run-multiple-schedules.md

@@ -10,8 +10,6 @@ nav_order: 11
 Multiple backup schedules with different configuration can be configured by mounting an arbitrary number of configuration files (using the `.env` format) into `/etc/dockervolumebackup/conf.d`:
 
 ```yml
-version: '3'
-
 services:
   # ... define other services using the `data` volume here
   backup:

docs/how-tos/set-container-timezone.md

@@ -12,8 +12,6 @@ As the image is designed to be as small as possible, additional timezone data is
 In case you want to run your cron rules in your local timezone (respecting DST and similar), you can mount your Docker host's `/etc/timezone` and `/etc/localtime` in read-only mode:
 
 ```yml
-version: '3'
-
 services:
   backup:
     image: offen/docker-volume-backup:v2

docs/how-tos/set-up-notifications.md

@@ -12,8 +12,6 @@ parent: How Tos
 To send out email notifications on failed backup runs, provide SMTP credentials, a sender and a recipient:
 
 ```yml
-version: '3'
-
 services:
   backup:
     image: offen/docker-volume-backup:v2

docs/how-tos/stop-containers-during-backup.md

@@ -17,8 +17,6 @@ By default, any container that is labeled `docker-volume-backup.stop-during-back
 In case you need more fine grained control about which containers should be stopped (e.g. when backing up multiple volumes on different schedules), you can set the `BACKUP_STOP_DURING_BACKUP_LABEL` environment variable and then use the same value for labeling:
 
 ```yml
-version: '3'
-
 services:
   app:
     # definition for app ...