website: hardcode version banner for 0.1 docs

O.1 docs is deprecated. Let's inform user to switch the the latest version

Signed-off-by: user.email <jf@dagger.io>

docs/0.1.md

@@ -0,0 +1,16 @@
+---
+slug: /0.1
+displayed_sidebar: '0.1'
+---
+
+# Dagger 0.1
+
+This documentation is for dagger 0.1 which is no longer maintained.
+
+If you are still running dagger 0.1, we encourage you to upgrade to 0.2.
+These are the [current dagger 0.2 docs](/).
+
+If you need help migrating your plan, we will be happy to assist you!
+Simply reply to [this thread](https://github.com/dagger/dagger/discussions/1772) with a description of your configuration.
+If you've already started migrating, please let us know and share details of your progress and issues you're encountering.
+We will do our best to assist you!

docs/1214-migrate-from-dagger-0.1.md

@@ -1,6 +1,6 @@
 ---
 slug: /1214/migrate-from-dagger-0.1
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Migrate from Dagger 0.1

docs/administrator/1013-operator-manual.md

@@ -1,5 +1,6 @@
 ---
 slug: /1013/operator-manual/
+displayed_sidebar: "0.1"
 ---
 
 # Dagger Operator Manual

docs/core-concepts/1202-plan.md

@@ -1,6 +1,6 @@
 ---
 slug: /1202/plan
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # It all starts with a plan
@@ -20,6 +20,7 @@ Within this plan we can:
 This is our **Getting Started** todoapp plan structure:
 
 ```cue file=../tests/core-concepts/plan/structure.cue.fragment
+
 ```
 
 When the above plan gets executed via `dagger do build`, it produces the following output:

docs/core-concepts/1203-client.md

@@ -1,6 +1,6 @@
 ---
 slug: /1203/client
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Interacting with the client
@@ -18,11 +18,13 @@ displayed_sidebar: europa
 You may need to load a local directory as a `dagger.#FS` type in your plan:
 
 ```cue file=../tests/core-concepts/client/plans/fs.cue
+
 ```
 
 It’s also easy to write a file locally:
 
 ```cue file=../tests/core-concepts/client/plans/file.cue
+
 ```
 
 ## Using a local socket
@@ -40,6 +42,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
 <TabItem value="unix" label="Linux/macOS">
 
 ```cue file=../tests/core-concepts/client/plans/unix.cue
+
 ```
 
 </TabItem>
@@ -47,6 +50,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
 <TabItem value="windows" label="Windows">
 
 ```cue file=../tests/core-concepts/client/plans/windows.cue
+
 ```
 
 </TabItem>
@@ -59,6 +63,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
 Environment variables can be read from the local machine as strings or secrets, just specify the type:
 
 ```cue file=../tests/core-concepts/client/plans/env.cue
+
 ```
 
 ## Running commands
@@ -66,6 +71,7 @@ Environment variables can be read from the local machine as strings or secrets,
 Sometimes you need something more advanced that only a local command can give you:
 
 ```cue file=../tests/core-concepts/client/plans/cmd.cue
+
 ```
 
 :::tip
@@ -77,4 +83,5 @@ You can also capture `stderr` for errors and provide `stdin` for input.
 If you need the current platform though, there’s a more portable way than running `uname` like in the previous example:
 
 ```cue file=../tests/core-concepts/client/plans/platform.cue
+
 ```

docs/core-concepts/1204-secrets.md

@@ -1,6 +1,6 @@
 ---
 slug: /1204/secrets
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # How to use secrets
@@ -28,6 +28,7 @@ dagger.#Plan & {
 You may need to trim the whitespace, especially when reading from a file:
 
 ```cue file=../tests/core-concepts/secrets/plans/file.cue
+
 ```
 
 ## SOPS
@@ -36,9 +37,9 @@ There’s many ways to store encrypted secrets in your git repository. If you us
 
 ```yaml title="secrets.yaml"
 myToken: ENC[AES256_GCM,data:AlUz7g==,iv:lq3mHi4GDLfAssqhPcuUIHMm5eVzJ/EpM+q7RHGCROU=,tag:dzbT5dEGhMnHbiRTu4bHdg==,type:str]
-sops:
+sops: ...
-    ...
 ```
 
 ```cue file=../tests/core-concepts/secrets/plans/sops.cue title="main.cue"
+
 ```

docs/core-concepts/1206-packages.md

@@ -1,6 +1,6 @@
 ---
 slug: /1206/packages
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Create your own package

docs/core-concepts/1207-caching.md

@@ -1,6 +1,6 @@
 ---
 slug: /1207/caching
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Make your builds fast

docs/core-concepts/1213-dagger-cue.md

@@ -1,6 +1,6 @@
 ---
 slug: /1213/api
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Dagger CUE API
@@ -16,7 +16,7 @@ Developers of other Dagger packages are expected to build on top of these core p
 `#Plan` defines the structure of a Dagger plan - a complete configuration executable by `dagger do`
 
 | Definition | File                                                                                   | Description                                          |
-| :--        | :--                                                                                    | :--                                                  |
+| :--------- | :------------------------------------------------------------------------------------- | :--------------------------------------------------- |
 | `#Plan`    | [plan.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/plan.cue) | A special kind of program which `dagger` can execute |
 
 ### Core types
@@ -24,7 +24,7 @@ Developers of other Dagger packages are expected to build on top of these core p
 Dagger extends the CUE type system with the following core types:
 
 | Definition     | File                                                                                        | Description                                           |
-| :--            | :--                                                                                         | :--                                                   |
+| :------------- | :------------------------------------------------------------------------------------------ | :---------------------------------------------------- |
 | `#Address`     | [types.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue)    | Network service address                               |
 | `#CacheDir`    | [exec.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/exec.cue) | A (best effort) persistent cache dir                  |
 | `#FS`          | [types.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue)    | Reference to a filesystem tree                        |
@@ -42,13 +42,13 @@ Dagger extends the CUE type system with the following core types:
 Dagger works by executing actions in a certain order and passing data between actions in a certain layout.
 
 Developers can combine actions into higher-level actions, which in turn can be combined into even higher-level actions,
-and so on at arbitrary levels of depth. At the bottom of this abstraction stack are *core actions*: these
+and so on at arbitrary levels of depth. At the bottom of this abstraction stack are _core actions_: these
 are implemented by Dagger itself, and are always available.
 
 The following core actions are available:
 
 | Definition      | File                                                                                              | Description                                                           |
-| :--             | :--                                                                                               | :--                                                                   |
+| :-------------- | :------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------- |
 | `#Copy`         | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue)           | Copy files between two filesystem trees                               |
 | `#DecodeSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Decode a secret without leaking its contents                          |
 | `#Diff`         | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue)           | Extract the difference between two filesystems as its own file system |

docs/core-concepts/1221-action.md

@@ -1,6 +1,6 @@
 ---
 slug: /1221/action
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Dagger Actions
@@ -11,7 +11,7 @@ software component that can be safely shared, and repeatably executed by any Dag
 
 Actions can be executed directly with `dagger do`, or integrated as a component of a more complex action.
 
-There are two types of actions: *core actions* and *composite actions*.
+There are two types of actions: _core actions_ and _composite actions_.
 
 ## Core Actions
 
@@ -36,7 +36,7 @@ A composite action's lifecycle has 4 stages:
 
 ### Definition
 
-A new action is *defined* in a declarative template called a [CUE definition](https://cuetorials.com/overview/foundations/#definitions). This definition describes the action's inputs, outputs, sub-actions, and the wiring between them.
+A new action is _defined_ in a declarative template called a [CUE definition](https://cuetorials.com/overview/foundations/#definitions). This definition describes the action's inputs, outputs, sub-actions, and the wiring between them.
 
 Here is an example of a simple action definition:
 
@@ -71,9 +71,9 @@ Note that this action includes one sub-action: `core.#WriteFile`. An action can
 
 Also note the free-form structure: an action definition is not structured by a rigid schema. It is simply a CUE struct with fields of various types.
 
-* "inputs" are simply fields which are not complete, and therefore can receive an external value at integration. For example, `dir` and `name` are inputs.
+- "inputs" are simply fields which are not complete, and therefore can receive an external value at integration. For example, `dir` and `name` are inputs.
-* "outputs" are simply fields which produce a value that can be referenced externally at integration. For example, `result` is an output.
+- "outputs" are simply fields which produce a value that can be referenced externally at integration. For example, `result` is an output.
-* "sub-actions" are simply fields which contain another action definition. For example, `write` is a sub-action.
+- "sub-actions" are simply fields which contain another action definition. For example, `write` is a sub-action.
 
 There are no constraints to an action's field names or types.
 
@@ -83,11 +83,11 @@ Action definitions cannot be executed directly: they must be integrated into a p
 
 A plan is an execution context for actions. It specifies:
 
-* What actions to present to the end user
+- What actions to present to the end user
-* Dependencies between those tasks, if any
+- Dependencies between those tasks, if any
-* Interactions between the tasks and the client system, if any
+- Interactions between the tasks and the client system, if any
 
-Actions are integrated into a plan by *merging* their CUE definition into the plan's CUE definition.
+Actions are integrated into a plan by _merging_ their CUE definition into the plan's CUE definition.
 
 Here is an example of a plan:
 
@@ -110,7 +110,7 @@ dagger.#Plan & {
 }
 ```
 
-Note that `#AddHello` was integrated *directly* into the plan, whereas `core.#WriteFile` was integrated *indirectly*, by virtue of being a sub-action of `#AddHello`.
+Note that `#AddHello` was integrated _directly_ into the plan, whereas `core.#WriteFile` was integrated _indirectly_, by virtue of being a sub-action of `#AddHello`.
 
 To learn more about the structure of a plan, see [it all begins with a plan](./1202-plan.md).
 

docs/getting-started/1200-local-dev.md

@@ -1,6 +1,6 @@
 ---
 slug: /1200/local-dev
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # CI/CD in your local dev

docs/getting-started/1201-ci-environment.md

@@ -1,6 +1,6 @@
 ---
 slug: /1201/ci-environment
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Integrating with your CI environment
@@ -98,7 +98,6 @@ build:
   extends: [.dagger]
   variables:
     ARGS: build
-
 ```
 
 </TabItem>

docs/getting-started/1220-vs.md

@@ -1,6 +1,6 @@
 ---
 slug: /1220/vs
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Dagger vs. Other Software
@@ -9,16 +9,16 @@ displayed_sidebar: europa
 
 Dagger does not replace your CI: it improves it by adding a portable development layer on top of it.
 
-* Dagger runs on all major CI products. This *reduces CI lock-in*: you can change CI without rewriting all your pipelines.
+- Dagger runs on all major CI products. This _reduces CI lock-in_: you can change CI without rewriting all your pipelines.
-* Dagger also runs on your dev machine. This allows *dev/CI parity*: the same pipelines can be used in CI and development.
+- Dagger also runs on your dev machine. This allows _dev/CI parity_: the same pipelines can be used in CI and development.
 
 ## Dagger vs. PaaS (Heroku, Firebase, etc.)
 
 Dagger is not a PaaS, but you can use it to add PaaS-like features to your CICD pipelines:
 
-* A simple deployment abstraction for the developer
+- A simple deployment abstraction for the developer
-* A catalog of possible customizations, managed by the platform team
+- A catalog of possible customizations, managed by the platform team
-* On-demand staging or development environments
+- On-demand staging or development environments
 
 Using Dagger is a good way to get many of the benefits of a PaaS (developer productivity and peace of mind),
 without giving up the benefits of custom CICD pipelines (full control over your infrastructure and tooling).
@@ -29,15 +29,15 @@ Most applications have a custom deploy script that usually gets the job done, bu
 
 Using Dagger, you have two options:
 
-1. You can *replace* your script with a DAG that is better in every way: more features, more reliable, faster, easier to read, improve, and debug.
+1. You can _replace_ your script with a DAG that is better in every way: more features, more reliable, faster, easier to read, improve, and debug.
-2. You can *extend* your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later.
+2. You can _extend_ your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later.
 
 ## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK)
 
 Dagger is the perfect complement to an IaC tool.
 
-* IaC tools help infrastructure teams answer questions like: what is the current state of my infrastructure? What is its desired state? And how do I get there?
+- IaC tools help infrastructure teams answer questions like: what is the current state of my infrastructure? What is its desired state? And how do I get there?
-* Dagger helps CICD teams answer question like: what work needs to be done to deliver my application, in what order, and how do I orchestrate it?
+- Dagger helps CICD teams answer question like: what work needs to be done to deliver my application, in what order, and how do I orchestrate it?
 
 It is very common for a Dagger configuration to integrate with at least one IaC tool.
 

docs/getting-started/index.md

@@ -1,6 +1,6 @@
 ---
 slug: /
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Getting Started

docs/guides/1205-container-images.md

@@ -1,6 +1,6 @@
 ---
 slug: /1205/container-images
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Building container images
@@ -14,6 +14,7 @@ Dagger can natively load and execute Dockerfiles. This is recommended in cases w
 Here's a simple example of a [Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) build:
 
 ```cue file=../tests/core-concepts/container-images/simple/with-dockerfile.cue
+
 ```
 
 ## Specifying a build in CUE
@@ -23,6 +24,7 @@ You can specify your container build natively in CUE, using the official Docker
 Native CUE builds have the same backend as Dockerfile builds, so all the same features are available. Since CUE is a more powerful language than the Dockerfile syntax, every Dockerfile can be ported to an equivalent CUE configuration, but the opposite is not true. The following example produces the same image as above.
 
 ```cue file=../tests/core-concepts/container-images/simple/build.cue
+
 ```
 
 Because this build configuration is pure CUE, it can leverage the full power of Dagger's composition model.
@@ -32,6 +34,7 @@ Because this build configuration is pure CUE, it can leverage the full power of
 Building images in CUE gives you greater flexibility. For example, you can automate building multiple versions of an image, and deploy, all in Dagger:
 
 ```cue file=../tests/core-concepts/container-images/template/dagger.cue
+
 ```
 
 Now you can deploy all versions:
@@ -51,4 +54,5 @@ dagger do versions 8.0 build
 Another common pattern is [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). This allows you to have heavier build images during the build process, and copy the built artifacts into a cleaner and lighter image to run in production.
 
 ```cue file=../tests/core-concepts/container-images/multi-stage/dagger.cue
+
 ```

docs/guides/1216-docker-cli-load.md

@@ -1,6 +1,6 @@
 ---
 slug: /1216/docker-cli-load
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Loading a dagger image into a docker daemon
@@ -12,9 +12,11 @@ It can be useful to debug or test a build locally before pushing.
 ## Local daemon
 
 ```cue file=../plans/docker-cli-load/local.cue
+
 ```
 
 ## Remote daemon, via SSH
 
 ```cue file=../plans/docker-cli-load/ssh.cue
+
 ```

docs/guides/1217-docker-cli-run.md

@@ -1,6 +1,6 @@
 ---
 slug: /1217/docker-cli-run
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Running commands with the docker binary (CLI)
@@ -10,14 +10,17 @@ There's a `universe.dagger.io/docker/cli` package that allows you to run docker
 ## Local daemon
 
 ```cue file=../plans/docker-cli-run/local.cue
+
 ```
 
 ## Remote daemon, via SSH
 
 ```cue file=../plans/docker-cli-run/ssh.cue
+
 ```
 
 ## Remote daemon, via HTTPS
 
 ```cue file=../plans/docker-cli-run/tcp.cue
+
 ```

docs/guides/1218-cli-telemetry.md

@@ -1,6 +1,6 @@
 ---
 slug: /1218/cli-telemetry
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Understanding CLI Telemetry
@@ -15,10 +15,10 @@ us better understand how Dagger is used, and will allow us to improve your exper
 
 The following information is included in telemetry:
 
-* Dagger version
+- Dagger version
-* Platform information
+- Platform information
-* Command run
+- Command run
-* Anonymous device ID
+- Anonymous device ID
 
 We use telemetry for aggregate analysis, and do not tie telemetry events to a specific identity.
 

docs/guides/1226-coding-style.md

@@ -1,6 +1,6 @@
 ---
 slug: /1226/coding-style
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Package Coding Style
@@ -59,7 +59,7 @@ Choose `_camelCase` for private fields (implementation details).
 }
 ```
 
-## Definitions for *schemas*, fields for concrete *implementations*
+## Definitions for _schemas_, fields for concrete _implementations_
 
 ```cue
 // good, defines a schema
@@ -187,7 +187,7 @@ run: bash.#Run & {
 
 ## Don’t inline scripts
 
-Avoid inlining scripts (e.g., *sh*, *py*, etc). Instead, put them in their own files
+Avoid inlining scripts (e.g., _sh_, _py_, etc). Instead, put them in their own files
 with proper extension, and use `core.#Source` to import into CUE. This allows linting
 and avoids some limitations (script size, escaping).
 
@@ -259,7 +259,7 @@ run: python.#Run & {
 }
 ```
 
-## Favor disjunctions over *if* conditions
+## Favor disjunctions over _if_ conditions
 
 ```cue
 // bad
@@ -283,7 +283,7 @@ if type == "cache" {
 }
 ```
 
-## Favor templates over *for* loops
+## Favor templates over _for_ loops
 
 ```cue
 // bad
@@ -334,11 +334,11 @@ files: {
 }
 ```
 
-## Use *top* to match anything
+## Use _top_ to match anything
 
 From [CUE](https://cuelang.org/docs/references/spec/#values-1):
 
-> At the top of the lattice is the single ancestor of all values, called *top*, denoted `_` in CUE. Every value is an instance of top.
+> At the top of the lattice is the single ancestor of all values, called _top_, denoted `_` in CUE. Every value is an instance of top.
 
 There's a recurring theme when you have a template and need to create instances from it:
 

docs/introduction/1000-what_is.md

@@ -1,16 +1,16 @@
 ---
-slug: /1200/what/
+slug: /1000/what/
 ---
 
 # What is Dagger?
 
 Dagger is a portable devkit for CICD. It helps you develop powerful CICD pipelines that can run anywhere.
 
-* Choose from a wide catalog of reusable actions, or create your own in your favorite programming language.
+- Choose from a wide catalog of reusable actions, or create your own in your favorite programming language.
-* Tie it all together with [CUE](https://cuelang.org), the next-generation declarative language invented at Google. No more YAML hell!
+- Tie it all together with [CUE](https://cuelang.org), the next-generation declarative language invented at Google. No more YAML hell!
-* Unify dev and CI. The same Dagger pipeline can run on your dev machine or in CI. All you need is a Docker-compatible runtime.
+- Unify dev and CI. The same Dagger pipeline can run on your dev machine or in CI. All you need is a Docker-compatible runtime.
-* Avoid CI lock-in. Dagger runs natively on GitHub Actions, GitLab, CircleCI, Jenkins, AWS Codebuild, Tekton, and more.
+- Avoid CI lock-in. Dagger runs natively on GitHub Actions, GitLab, CircleCI, Jenkins, AWS Codebuild, Tekton, and more.
-* Test and debug your pipelines locally; catch configuration errors in seconds with static type checking.
+- Test and debug your pipelines locally; catch configuration errors in seconds with static type checking.
 
 <img src="/img/what-is-dagger.png" alt="Dagger_Website_Ship" style={{maxWidth: '50%'}} />
 

docs/new.sh

@@ -24,7 +24,7 @@ function new() {
 	cat <<- EOF > "$filename"
 		---
 		slug: /$next/$name
-		displayed_sidebar: europa
+		displayed_sidebar: "0.2"
 		---
 EOF
 }

docs/references/1222-core-actions-reference.md

@@ -1,6 +1,6 @@
 ---
 slug: /1222/core-actions-reference
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Core Actions Reference
@@ -14,7 +14,7 @@ The following core actions are available:
 ## Core Actions related to filesystem trees
 
 | Definition   | File                                                                                    | Description                                                           |
-| :--             | :--                                                                                               | :--                                                                   |
+| :----------- | :-------------------------------------------------------------------------------------- | :-------------------------------------------------------------------- |
 | `#Copy`      | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Copy files between two filesystem trees                               |
 | `#Diff`      | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Extract the difference between two filesystems as its own file system |
 | `#Merge`     | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Merge multiple filesystem trees                                       |
@@ -28,7 +28,7 @@ The following core actions are available:
 ## Core Actions related to secrets
 
 | Definition      | File                                                                                              | Description                                              |
-| :--             | :--                                                                                               | :--                                                                   |
+| :-------------- | :------------------------------------------------------------------------------------------------ | :------------------------------------------------------- |
 | `#DecodeSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Decode a secret without leaking its contents             |
 | `#NewSecret`    | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Create a new a secret from a filesystem tree             |
 | `#TrimSecret`   | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Trim leading and trailing space characters from a secret |
@@ -36,7 +36,7 @@ The following core actions are available:
 ## Core Actions related to containers
 
 | Definition    | File                                                                                          | Description                                        |
-| :--             | :--                                                                                               | :--                                                                   |
+| :------------ | :-------------------------------------------------------------------------------------------- | :------------------------------------------------- |
 | `#Dockerfile` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Build a container image using a Dockerfile         |
 | `#Exec`       | [exec.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/exec.cue)   | Execute a command in a docker-compatible container |
 | `#Export`     | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Export a docker image as a tar archive             |
@@ -47,6 +47,6 @@ The following core actions are available:
 ## Core Actions related to remote data sources
 
 | Definition   | File                                                                                        | Description                                    |
-| :--             | :--                                                                                               | :--                                                                   |
+| :----------- | :------------------------------------------------------------------------------------------ | :--------------------------------------------- |
 | `#GitPull`   | [git.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/git.cue)   | Download a repository from a remote git server |
 | `#HTTPFetch` | [http.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/http.cue) | Get a file from an HTTP server                 |

docs/use-cases/1208-phoenix-kubernetes.md

@@ -1,6 +1,6 @@
 ---
 slug: /1208/phoenix-kubernetes
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Elixir/Phoenix on Kubernetes

docs/use-cases/1209-docusaurus-netlify.md

@@ -1,6 +1,6 @@
 ---
 slug: /1209/docusaurus-netlify
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Docusaurus on Netlify

docs/use-cases/1210-go-goreleaser.md

@@ -1,6 +1,6 @@
 ---
 slug: /1210/go-goreleaser
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Go with GoReleaser

docs/use-cases/1211-go-docker-swarm.md

@@ -1,6 +1,6 @@
 ---
 slug: /1211/go-docker-swarm
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Go on Docker Swarm

docs/use-cases/1212-svelte-vercel.md

@@ -1,6 +1,6 @@
 ---
 slug: /1212/svelte-vercel
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Svelte on Vercel

docs/use-cases/1219-go-docker-hub.md

@@ -1,6 +1,6 @@
 ---
 slug: /1219/go-docker-hub
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Go on Docker Hub
@@ -22,6 +22,7 @@ You can indeed choose which files to include. Since it's a Golang project
 it should contain the module and all Go source files:
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/retrieve-go-project/dagger.cue
+
 ```
 
 :::tip
@@ -38,6 +39,7 @@ to build your pipeline, but your project may use `CGO` or any external dependenc
 You can customize the base image to install required dependencies:
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/base.cue.fragment
+
 ```
 
 ## Run unit tests
@@ -48,9 +50,11 @@ Use the [#Test](https://github.com/dagger/dagger/blob/main/pkg/universe.dagger.i
 definition:
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/test.cue.fragment
+
 ```
 
 <!-- FIXME(TomChv): we should write a bunch of documentation about TDD with dagger -->
+
 :::tip
 You can also use Dagger to write integration tests.
 :::
@@ -63,6 +67,7 @@ Use the [#Build](https://github.com/dagger/dagger/blob/main/pkg/universe.dagger.
 definition to do that:
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/build.cue.fragment
+
 ```
 
 :::tip
@@ -76,6 +81,7 @@ To make it usable for other users, you must put your binary in an image and set
 For optimization purposes, you can use alpine as the base image to contain your binary:
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/image.cue.fragment
+
 ```
 
 ## Push to Docker Hub
@@ -98,6 +104,7 @@ dagger.#Plan & {
 You can now push your image:
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/push.cue.fragment
+
 ```
 
 ## Complete CI/CD
@@ -106,6 +113,7 @@ After merging all examples, you will have a complete CI/CD to deliver a Go
 binary on Docker Hub.
 
 ```cue file=../tests/use-cases/ci-cd-for-go-project/complete-ci-cd/dagger.cue
+
 ```
 
 You can then use `dagger do` to select which action you want to run.

website/sidebars.js

@@ -10,71 +10,7 @@
  */
 
 module.exports = {
-  preEuropa: [
+  "0.2": [
-    {
-      type: "category",
-      label: "Introduction",
-      collapsible: true,
-      items: ["introduction/what_is", "introduction/vs"],
-    },
-    {
-      type: "doc",
-      id: "install",
-    },
-    {
-      type: "category",
-      label: "Learn Dagger",
-      collapsible: true,
-      collapsed: false,
-      items: [
-        "learn/what_is_cue",
-        "learn/get-started",
-        "learn/google-cloud-run",
-        "learn/kubernetes",
-        "learn/aws-cloudformation",
-        "learn/github-actions",
-        "learn/dev-cue-package",
-        "learn/package-manager",
-      ],
-    },
-    {
-      type: "category",
-      label: "Use Cases",
-      collapsible: true,
-      collapsed: true,
-      items: ["use-cases/ci"],
-    },
-    {
-      type: "category",
-      label: "Universe - API Reference",
-      collapsible: true,
-      collapsed: true,
-      // generate the sidebar for reference doc automatically
-      items: [
-        {
-          type: "autogenerated",
-          dirName: "reference",
-        },
-      ],
-    },
-    {
-      type: "category",
-      label: "Administrator Manual",
-      collapsible: true,
-      collapsed: true,
-      items: ["administrator/operator-manual"],
-    },
-    {
-      type: "link",
-      label: "Dagger 0.2 ➡️",
-      href: "/",
-    },
-  ],
-  europa: [
-    {
-      type: "doc",
-      id: "migrate-from-dagger-0.1",
-    },
     {
       type: "category",
       label: "Getting Started",
@@ -142,10 +78,74 @@ module.exports = {
         "use-cases/go-docker-swarm",
       ],
     },
+    {
+      type: "doc",
+      id: "migrate-from-dagger-0.1",
+    },
     {
       type: "link",
       label: "⬅️ Dagger 0.1",
-      href: "/1200/what/",
+      href: "/0.1",
+    },
+  ],
+  "0.1": [
+    {
+      type: "category",
+      label: "Introduction",
+      collapsible: true,
+      items: ["introduction/what_is", "introduction/vs"],
+    },
+    {
+      type: "doc",
+      id: "install",
+    },
+    {
+      type: "category",
+      label: "Learn Dagger",
+      collapsible: true,
+      collapsed: false,
+      items: [
+        "learn/what_is_cue",
+        "learn/get-started",
+        "learn/google-cloud-run",
+        "learn/kubernetes",
+        "learn/aws-cloudformation",
+        "learn/github-actions",
+        "learn/dev-cue-package",
+        "learn/package-manager",
+      ],
+    },
+    {
+      type: "category",
+      label: "Use Cases",
+      collapsible: true,
+      collapsed: true,
+      items: ["use-cases/ci"],
+    },
+    {
+      type: "category",
+      label: "Universe - API Reference",
+      collapsible: true,
+      collapsed: true,
+      // generate the sidebar for reference doc automatically
+      items: [
+        {
+          type: "autogenerated",
+          dirName: "reference",
+        },
+      ],
+    },
+    {
+      type: "category",
+      label: "Administrator Manual",
+      collapsible: true,
+      collapsed: true,
+      items: ["administrator/operator-manual"],
+    },
+    {
+      type: "link",
+      label: "Dagger 0.2 ➡️",
+      href: "/",
     },
   ],
 };

website/src/components/DeprecatedVersionBanner.js

@@ -0,0 +1,12 @@
+import React from 'react'
+
+function DeprecatedVersionBanner() {
+  return (
+      <div class="theme-doc-version-banner alert alert--warning margin-bottom--md" role="alert">
+        <div>This is documentation for Dagger <b>0.1</b>, which is no longer actively maintained.</div>
+        <div class="margin-top--md">For up-to-date documentation, see the <b><a href="/">latest version</a></b> (0.2).</div>
+      </div>
+  )
+}
+
+export default DeprecatedVersionBanner

website/src/theme/DocPage/index.js

@@ -27,6 +27,7 @@ import {
 } from '@docusaurus/theme-common';
 import Head from '@docusaurus/Head';
 import amplitude from 'amplitude-js';
+import DeprecatedVersionBanner from '../../components/DeprecatedVersionBanner';
 
 function DocPageContent({
   currentDocRoute,
@@ -171,6 +172,9 @@ function DocPage(props) {
             currentDocRoute={currentDocRoute}
             versionMetadata={versionMetadata}
             sidebarName={sidebarName}>
+            {currentDocRoute.sidebar === '0.1' && (
+            <DeprecatedVersionBanner />
+            )}
             <div data-cy="cy-doc-content">
               {renderRoutes(docRoutes, {
                 versionMetadata,