Added getting started to documentation

docs/articles/intro/getting-started/toc.yml

@@ -0,0 +1,10 @@
+- name: Tutorial Overview
+  href: tutorial-overview.md
+- name: Part 1. Top-level Architecture
+  href: tutorial-1.md
+- name: Part 2. The Device Actor
+  href: tutorial-2.md
+- name: Part 3. Device Groups and Manager
+  href: tutorial-3.md
+- name: Part 4. Querying a Group of Devices
+  href: tutorial-4.md

docs/articles/intro/tutorial-1.md → docs/articles/intro/getting-started/tutorial-1.md

@@ -3,53 +3,7 @@ uid: tutorial-1
 title: Part 1. Top-level Architecture
 ---
 
-# Part 1: Top-Level Architecture
-
-In this and the following chapters, we will build a sample Akka.NET application
-to introduce you to the language of actors and how solutions can be formulated
-with them. It is a common hurdle for beginners to translate their project into
-actors even though they don't understand what they do on the high-level. We will
-build the core logic of a small application and this will serve as a guide for
-common patterns that will help to kickstart Akka.NET projects.
-
-The application we aim to write will be a simplified IoT system where devices,
-installed at the home of users, can report temperature data from sensors. Users
-will be able to query the current state of these sensors. To keep things simple,
-we will not actually expose the application via HTTP or any other external API,
-we will, instead, concentrate only on the core logic. However, we will write
-tests for the pieces of the application to get comfortable and proficient with
-testing actors early on.
-
-## Our Goals for the IoT System
-
-We will build a simple IoT application with the bare essentials to demonstrate
-designing an Akka.NET-based system. The application will consist of two main
-components:
-
-* **Device data collection:** This component has the responsibility to maintain
-   a local representation of the otherwise remote devices. The devices will be
-   organized into device groups, grouping together sensors belonging to a home.
-* **User dashboards:** This component has the responsibility to periodically
-   collect data from the devices for a logged in user and present the results as
-   a report.
-
-For simplicity, we will only collect temperature data for the devices, but in a
-real application our local representations for a remote device, which we will
-model as an actor, would have many more responsibilities. Among others; reading
-the configuration of the device, changing the configuration, checking if the
-devices are unresponsive, etc. We leave these complexities for now as they can
-be easily added as an exercise.
-
-We will also not address the means by which the remote devices communicate with
-the local representations (actors). Instead, we just build an actor based API
-that such a network protocol could use. We will use tests for our API everywhere
-though.
-
-The architecture of the application will look like this:
-
-![box diagram of the architecture](/images/arch_boxes_diagram.png)
-
-## Top Level Architecture
+# Part 1: Top Level Architecture
 
 When writing prose, the hardest part is usually to write the first couple of
 sentences. There is a similar feeling when trying to build an Akka.NET system:
@@ -98,7 +52,7 @@ from user, or system, actors end up.
 > has. This special entity is called the "Bubble-Walker". This special entity is
 > invisible for the user and only has uses internally.
 
-### Structure of an IActorRef and Paths of Actors
+## Structure of an IActorRef and Paths of Actors
 
 The easiest way to see this in action is to simply print `IActorRef` instances.
 In this small experiment, we print the reference of the first actor we create
@@ -141,7 +95,7 @@ The last part of the actor reference, like `#1053618476` is a unique identifier
 of the actor living under the path. This is usually not something the user needs
 to be concerned with, and we leave the discussion of this field for later.
 
-### Hierarchy and Lifecycle of Actors
+## Hierarchy and Lifecycle of Actors
 
 We have so far seen that actors are organized into a **strict hierarchy**. This
 hierarchy consists of a predefined upper layer of three actors (the root
@@ -196,7 +150,7 @@ The family of these lifecycle hooks is rich, and we recommend reading [the actor
 lifecycle](xref:untyped-actor-api#actor-lifecycle) section of the reference for
 all details.
 
-### Hierarchy and Failure Handling (Supervision)
+## Hierarchy and Failure Handling (Supervision)
 
 Parents and children are not only connected by their lifecycles. Whenever an
 actor fails (throws an exception or an unhandled exception bubbles out from
@@ -240,7 +194,7 @@ see how the output changes.
 For the impatient, we also recommend looking into the [supervision reference
 page](xref:supervision) for more in-depth details.
 
-### The First Actor
+## The First Actor
 
 Actors are organized into a strict tree, where the lifecycle of every child is
 tied to the parent and where parents are responsible for deciding the fate of
@@ -280,7 +234,7 @@ All we need now is to tie this up with a class with the `main` entry point:
 This application does very little for now, but we have the first actor in place
 and we are ready to extend it further.
 
-## What Is Next?
+# What Is Next?
 
 In the following chapters we will grow the application step-by-step:
 

docs/articles/intro/getting-started/tutorial-overview.md

@@ -0,0 +1,57 @@
+---
+uid: tutorial-overview
+title: Tutorial Overview
+---
+
+# Tutorial Overview
+
+In this and the following chapters, we will build a sample Akka.NET application
+to introduce you to the language of actors and how solutions can be formulated
+with them. It is a common hurdle for beginners to translate their project into
+actors even though they don't understand what they do on the high-level. We will
+build the core logic of a small application and this will serve as a guide for
+common patterns that will help to kickstart Akka.NET projects.
+
+The application we aim to write will be a simplified IoT system where devices,
+installed at the home of users, can report temperature data from sensors. Users
+will be able to query the current state of these sensors. To keep things simple,
+we will not actually expose the application via HTTP or any other external API,
+we will, instead, concentrate only on the core logic. However, we will write
+tests for the pieces of the application to get comfortable and proficient with
+testing actors early on.
+
+## Our Goals for the IoT System
+
+We will build a simple IoT application with the bare essentials to demonstrate
+designing an Akka.NET-based system. The application will consist of two main
+components:
+
+* **Device data collection:** This component has the responsibility to maintain
+   a local representation of the otherwise remote devices. The devices will be
+   organized into device groups, grouping together sensors belonging to a home.
+* **User dashboards:** This component has the responsibility to periodically
+   collect data from the devices for a logged in user and present the results as
+   a report.
+
+For simplicity, we will only collect temperature data for the devices, but in a
+real application our local representations for a remote device, which we will
+model as an actor, would have many more responsibilities. Among others; reading
+the configuration of the device, changing the configuration, checking if the
+devices are unresponsive, etc. We leave these complexities for now as they can
+be easily added as an exercise.
+
+We will also not address the means by which the remote devices communicate with
+the local representations (actors). Instead, we just build an actor based API
+that such a network protocol could use. We will use tests for our API everywhere
+though.
+
+The architecture of the application will look like this:
+
+![box diagram of the architecture](/images/arch_boxes_diagram.png)
+
+This tutorial is divided into four parts:
+
+* [Part 1: Top-level Architecture](../getting-started/tutorial-1.html)
+* [Part 2. The Device Actor](../getting-started/tutorial-2.html)
+* [Part 3. Device Groups and Manager](../getting-started/tutorial-3.html)
+* [Part 4. Querying a Group of Devices](../getting-started/tutorial-4.html)

docs/articles/intro/toc.yml

@@ -0,0 +1,12 @@
+- name: What is Akka.NET?
+  href: what-is-akka.md
+- name: What problems does the actor model solve?
+  href: what-problems-does-actor-model-solve.md
+- name: Akka.NET Libraries and Modules
+  href: modules.md
+- name: Use-case and Deployment Scenarios
+  href: use-case-and-deployment-scenarios.md
+- name: Production Users and Use Cases for Akka.NET
+  href: akka-users.md
+- name: Getting Started
+  href: getting-started/toc.yml

docs/articles/intro/tutorial-1.html

@@ -0,0 +1,10 @@
+<!DOCTYPE html>
+<html>
+   <head>
+      <title>Part 1. Top-level Architecture</title>
+      <meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-1.html" />
+   </head>
+   <body>
+      <p>This page has been moved to <a href="../intro/getting-started/tutorial-1.html">Part 1. Top-level Architecture</a>.</p>
+   </body>
+</html>

docs/articles/intro/tutorial-2.html

@@ -0,0 +1,10 @@
+<!DOCTYPE html>
+<html>
+   <head>
+      <title>Part 2. The Device Actor</title>
+      <meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-2.html" />
+   </head>
+   <body>
+      <p>This page has been moved to <a href="../intro/getting-started/tutorial-2.html">Part 2. The Device Actor</a>.</p>
+   </body>
+</html>

docs/articles/intro/tutorial-3.html

@@ -0,0 +1,10 @@
+<!DOCTYPE html>
+<html>
+   <head>
+      <title>Part 3. Device Groups and Manager</title>
+      <meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-3.html" />
+   </head>
+   <body>
+      <p>This page has been moved to <a href="../intro/getting-started/tutorial-3.html">Part 3. Device Groups and Manager</a>.</p>
+   </body>
+</html>

docs/articles/intro/tutorial-4.html

@@ -0,0 +1,10 @@
+<!DOCTYPE html>
+<html>
+   <head>
+      <title>Part 4. Querying a Group of Devices</title>
+      <meta http-equiv = "refresh" content="1;url=../intro/getting-started/tutorial-4.html" />
+   </head>
+   <body>
+      <p>This page has been moved to <a href="../intro/getting-started/tutorial-4.html">Part 4. Querying a Group of Devices</a>.</p>
+   </body>
+</html>

docs/articles/toc.yml

@@ -1,23 +1,5 @@
 - name: Introduction
-  items:
-  - name: What is Akka.NET?
-    href: intro/what-is-akka.md
-  - name: What problems does the actor model solve?
-    href: intro/what-problems-does-actor-model-solve.md
-  - name: Akka.NET Libraries and Modules
-    href: intro/modules.md
-  - name: Part 1. Top-level Architecture
-    href: intro/tutorial-1.md
-  - name: Part 2. The Device Actor
-    href: intro/tutorial-2.md
-  - name: Part 3. Device Groups and Manager
-    href: intro/tutorial-3.md
-  - name: Part 4. Querying a Group of Devices
-    href: intro/tutorial-4.md
-  - name: Use-case and Deployment Scenarios
-    href: intro/use-case-and-deployment-scenarios.md
-  - name: Production Users and Use Cases for Akka.NET
-    href: intro/akka-users.md
+  href: intro/toc.yml
 - name: Concepts
   items:
   - name: Terminology, Concepts

src/common.props

@@ -2,7 +2,7 @@
   <PropertyGroup>
     <Copyright>Copyright © 2013-2021 Akka.NET Team</Copyright>
     <Authors>Akka.NET Team</Authors>
-    <VersionPrefix>1.4.28</VersionPrefix>
+    <VersionPrefix>1.4.32</VersionPrefix>
     <PackageIcon>akkalogo.png</PackageIcon>
     <PackageProjectUrl>https://github.com/akkadotnet/akka.net</PackageProjectUrl>
     <PackageLicenseUrl>https://github.com/akkadotnet/akka.net/blob/master/LICENSE</PackageLicenseUrl>
@@ -32,29 +32,7 @@
     <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
   </PropertyGroup>
   <PropertyGroup>
-    <PackageReleaseNotes>Maintenance Release for Akka.NET 1.4**
-Akka.NET v1.4.28 is a minor release that contains some enhancements for Akka.Streams and some bug fixes.
-New Akka.Streams Stages**
-Akka.NET v1.4.28 includes two new Akka.Streams stages:
-[`Source.Never`](https://getakka.net/articles/streams/builtinstages.html#never) - a utility stage that never emits any elements, never completes, and never fails. Designed primarily for unit testing.
-[`Flow.WireTap`](https://getakka.net/articles/streams/builtinstages.html#wiretap) - the `WireTap` stage attaches a given `Sink` to a `Flow` without affecting any of the upstream or downstream elements. This stage is designed for performance monitoring and instrumentation of Akka.Streams graphs.
-In addition to these, here are some other changes introduced Akka.NET v1.4.28:
-[Akka.Streams: `Source` that flattens a `Task` source and keeps the materialized value](https://github.com/akkadotnet/akka.net/pull/5338)
-[Akka.Streams: made `GraphStageLogic.LogSource` virtual and change default `StageLogic` `LogSource`](https://github.com/akkadotnet/akka.net/pull/5360)
-[Akka.IO: `UdpListener` Responds IPv6 Bound message with IPv4 Bind message](https://github.com/akkadotnet/akka.net/issues/5344)
-[Akka.MultiNodeTestRunner: now runs on Linux and as a `dotnet test` package](https://github.com/akkadotnet/Akka.MultiNodeTestRunner/releases/tag/1.0.0) - we will keep you posted on this, as we're still working on getting Rider / VS Code / Visual Studio debugger-attached support to work correctly.
-[Akka.Persistence.Sql.Common: Cancel `DBCommand` after finish reading events by PersistenceId ](https://github.com/akkadotnet/akka.net/pull/5311) - *massive* performance fix for Akka.Persistence with many log entries on SQL-based journals.
-[Akka.Actor: `DefaultResizer` does not reisize when `ReceiveAsync` is used](https://github.com/akkadotnet/akka.net/issues/5327)
-If you want to see the [full set of changes made in Akka.NET v1.4.28, click here](https://github.com/akkadotnet/akka.net/milestone/59).
-| COMMITS | LOC+ | LOC- | AUTHOR |
-| --- | --- | --- | --- |
-| 16 | 2707 | 1911 | Sean Killeen |
-| 8 | 1088 | 28 | Ismael Hamed |
-| 6 | 501 | 261 | Gregorius Soedharmo |
-| 5 | 8 | 8 | dependabot[bot] |
-| 4 | 36 | 86 | Aaron Stannard |
-| 1 | 1 | 0 | Jarl Sveinung Flø Rasmussen |
-Special thanks for @SeanKilleen for contributing extensive Markdown linting and automated CI checks for that to our documentation! https://github.com/akkadotnet/akka.net/issues/5312</PackageReleaseNotes>
+    <PackageReleaseNotes>Placeholder for nightlies**</PackageReleaseNotes>
   </PropertyGroup>
   <!-- SourceLink support for all Akka.NET projects -->
   <ItemGroup>