Merge pull request eclipse-iceoryx#1123 from ApexAI/iox-#743-restruct…

…ure-iceoryx-io

iox-eclipse-iceoryx#743 Restructure iceoryx.io

.github/PULL_REQUEST_TEMPLATE.md

@@ -20,7 +20,7 @@
 [eca]: http://www.eclipse.org/legal/ECA.php
 [contributing]: https://github.com/eclipse-iceoryx/iceoryx/blob/master/CONTRIBUTING.md#coding-style
 [testing]: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/advanced/best-practice-for-testing.md
-[changelog]: https://github.com/eclipse-iceoryx/iceoryx/blob/master/CHANGELOG.md
+[changelog]: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/release-notes/iceoryx-unreleased.md
 
 ## Notes for Reviewer
 <!-- Items in addition to the checklist below that the reviewer should look for -->

CONTRIBUTING.md

@@ -53,7 +53,8 @@ Please make sure you have:
 3. All branches have the following naming format: `iox-#[issue]-branch-name` e.g. `iox-#123-super-duper-feature`
 4. All commits have the following naming format: `iox-#[issue] commit message` e.g. `iox-#123 implemented super-duper feature`
 5. All commits have been signed with `git commit -s`
-6. The CHANGELOG.md is updated with the GitHub issue that is closed by the Pull-Request (add to unreleased section)
+6. The `iceoryx-unreleased.md` in `doc/website/release-notes` is updated with the GitHub issue
+   that is closed by the Pull-Request
 7. You open your pull request towards the base branch `master`
 8. Link the pull request to the according GitHub issue and set the label accordingly
 

QUALITY_DECLARATION.md

@@ -23,7 +23,7 @@ On Git, the tags have a `v` prefix before the version numbers. A [release script
 
 `iceoryx` is at a stable version, i.e. `>= 1.0.0`. The latest valid release can be found on the [release page](https://github.com/eclipse-iceoryx/iceoryx/releases) of iceoryx.
 
-The change history can be found in the [CHANGELOG](https://github.com/eclipse-iceoryx/iceoryx/blob/master/CHANGELOG.md).
+The change history can be found in the [release notes section](https://iceoryx.io/latest/release-notes).
 
 ### Public API Declaration [1.iii]
 

doc/design/request_response_communication.md

@@ -40,34 +40,34 @@ In order to support asynchronous requests, a sequence ID should be part of each
 
 This is an overview of the untyped `Client` and `Server` classes.
 
-![simple class diagram](diagrams/request_response/overview_class.svg)
+![simple class diagram](overview_class.svg)
 
 The `Client` and `Server` are reusing the `ChunkSender` and `ChunkReceiver` building blocks. The `Client` uses a `ChunkSender` to send requests and a `ChunkReceiver` to get the responses while the `Server` uses a `ChunkReceiver` to get the requests and a `ChunkSender` to send the responses.
 
 #### Typed API
 
-![typed API](diagrams/request_response/typed_api.svg)
+![typed API](../website/images/typed_api.svg)
 
 Since the `Response` is tied to a specific `Request`, the `loan` method takes a `Request` to populate the `Response` with the correct settings.
 Alternatively, a `Request` could have a `createResponse` method which returns a `Response` with the correct settings.
 
 #### Untyped API
 
-![untyped API](diagrams/request_response/untyped_api.svg)
+![untyped API](../website/images/untyped_api.svg)
 
 Similar to the the typed API, `loan` takes a pointer to a `RequestHeader` to populate the `ResponseHeader` with the correct settings.
 
 #### Client Port
 
-![client port](diagrams/request_response/client_port.svg)
+![client port](../website/images/client_port.svg)
 
 The `ClientPortData` is located in the shared memory and contain only the data but no methods to access them.
 `ClientPortUser` is the class providing the methods for the user access and `ClientPortRouDi` provides the
 interface RouDi needs to connect the client to the server and to cleanup the port resources.
 
 #### Server Port
 
-![server port](diagrams/request_response/server_port.svg)
+![server port](../website/images/server_port.svg)
 
 Similar to the Client Port, the Server Port has `ServerPortData` which is located in the shared memory and contain only the data but no methods to access them.
 `ServerPortUser` is the class providing the methods for the user access and `ServerPortRouDi` provides the
@@ -77,7 +77,7 @@ It must be ensured that only one server with a given `ServiceDescription` can ru
 
 #### Request/Response Header
 
-![rpc header](diagrams/request_response/request_response_header.svg)
+![rpc header](../website/images/request_response_header.svg)
 
 Since request and response need to encode different meta-information, we also need different header for the messages.
 The common data is aggregated in `RpcBaseHeader` which contains a `cxx::UniqueId` to the `ClientChunkQueueData_t` and a sequence ID.
@@ -101,7 +101,7 @@ The `RequestHeader` has also the option to specify a message as fire and forget,
 
 #### Client/Server Options
 
-![client and server options](diagrams/request_response/client_and_server_options.svg)
+![client and server options](../website/images/client_and_server_options.svg)
 
 The client and server options can be used to control certain aspects of the clients and servers.
 Beside setting the capacity of the queues and defining whether a client should be connected and a server offering on creation,
@@ -114,14 +114,14 @@ If the options don't match, the client will not be connected to the server, simi
 
 The client is guided by the following state machine.
 
-![client state machine](diagrams/request_response/client_state_machine.svg)
+![client state machine](../website/images/client_state_machine.svg)
 
 Similar to the subscriber state machine, the client passes it's response queue with the `CONNECT` CaPro message to the server.
 The server will pass its request queue with the `ACK` CaPro message to the client.
 
 Following is a sequence diagram which shows all this cases
 
-![client and server service discovery](diagrams/request_response/client_and_server_service_discovery.svg)
+![client and server service discovery](../website/images/client_and_server_service_discovery.svg)
 
 ### Code example
 

doc/design/service-discovery.md

@@ -128,9 +128,9 @@ Contra:
 * Built-in topic approach based on `InterfacePort`'s
   * Sniff and intercept `CaproMessage`
 
-![overview diagram](diagrams/service-discovery/overview-alternative-b.svg)
+![overview diagram](../website/images/overview-alternative-b.svg)
 
-![sequence diagram](diagrams/service-discovery/sequence-diagram-alternative-b.svg)
+![sequence diagram](../website/images/sequence-diagram-alternative-b.svg)
 
 Pro:
 
@@ -172,9 +172,9 @@ Create a new publisher in RouDi which sends a `ServiceRegistryTopic`. This publi
 change in the service registry and to transmit the service discovery registry. The complete old service registry
 (saved locally) would be compared to the new service registry in a new class, extending the public user API.
 
-![overview diagram](diagrams/service-discovery/overview-alternative-d.svg)
+![overview diagram](../website/images/overview-alternative-d.svg)
 
-![sequence diagram](diagrams/service-discovery/sequence-diagram-alternative-d.svg)
+![sequence diagram](../website/images/sequence-diagram-alternative-d.svg)
 
 Pro:
 
@@ -416,5 +416,5 @@ PoshRuntime::findService(const capro::ServiceDescription& serviceDescription) no
 * [x] How does the SOME/IP-SD service discovery API look like?
 * [x] What does a `ros topic list` do in rmw_iceoryx?
 * [ ] Filter for `ServiceDescription::EventString` needed by AUTOSAR? Not supported by `ServiceRegistry::find()` as of today
-* [ ] Decision on mapping table between iceory and DDS (see [overview.md](../website/getting-started/overview.md))
+* [ ] Decision on mapping table between iceory and DDS (see [Overview](../website/getting-started/overview.md))
   * [ ] Current mapping table between iceoryx and DDS does not work with service discovery

doc/website/.pages

@@ -1,6 +1,10 @@
 nav:
   - index.md
   - getting-started
-  - API-reference
+  - concepts
+  - examples
+  - design
   - FAQ.md
   - advanced
+  - release-notes
+  - API-reference

doc/website/concepts/architecture.md

@@ -0,0 +1 @@
+# Architecture

doc/website/design/design_article.md

@@ -0,0 +1,3 @@
+# Design article
+
+<!-- @todo #743 Replace this file with several symlinks -->

doc/website/getting-started/examples/.pages → doc/website/examples/.pages

@@ -3,6 +3,7 @@ nav:
   - icehello.md
   - icedelivery.md
   - icedelivery_in_c.md
+  - icedocker.md
   - iceoptions.md
   - callbacks.md
   - callbacks_in_c.md

doc/website/getting-started/examples/complexdata.md → doc/website/examples/complexdata.md

@@ -2,5 +2,4 @@
 title: Sending/receiving some of the iceoryx STL container surrogates
 ---
 
-{! ./../iceoryx_examples/complexdata/README.md !}
-
+{! ../iceoryx/iceoryx_examples/complexdata/README.md !}

doc/website/getting-started/examples/index.md → doc/website/examples/index.md

@@ -1,5 +1,5 @@
 ---
-title: List of examples
+title: Examples
 ---
 
 {! ../iceoryx/iceoryx_examples/README.md !}

doc/website/getting-started/examples/user_header.md → doc/website/examples/user_header.md

@@ -2,4 +2,4 @@
 title: Using a user-header for additional meta-information like timestamps
 ---
 
-{! ../iceoryx_examples/user_header/README.md !}
+{! ../iceoryx/iceoryx_examples/user_header/README.md !}

doc/website/getting-started/.pages

@@ -2,4 +2,3 @@ nav:
   - what-is-iceoryx.md
   - overview.md
   - installation.md
-  - examples

doc/website/getting-started/overview.md

@@ -57,7 +57,7 @@ and exhaust memory. We have to handle this potential error since the expected cl
 attached. This means we get a warning (or an error when build in strict mode) when we don't handle it. We could also
 explicitly discard it with `IOX_DISCARD_RESULT` which is discouraged. If you want to know more about `expected`,
 take a look at
-[How optional and error values are returned in iceoryx](../advanced/how-optional-and-error-values-are-returned-in-iceoryx.md).
+[How optional and error values are returned in iceoryx](how-optional-and-error-values-are-returned-in-iceoryx.md).
 
 Let's create a corresponding subscriber.
 
@@ -66,8 +66,8 @@ iox::popo::Subscriber<CounterTopic> subscriber({"Group", "Instance", "CounterTop
 ```
 
 Now we can use the subscriber to receive data. For simplicity, we assume that we periodically check for new data. It
-is also possible to explicitly wait for data using the [WaitSet](../examples/waitset/) or the
-[Listener](../examples/callbacks/). The code to receive the data is the same, the only difference is the way we wake
+is also possible to explicitly wait for data using the [WaitSet](waitset.md) or the
+[Listener](callbacks.md). The code to receive the data is the same, the only difference is the way we wake
 up before checking for data.
 
 ```cpp
@@ -117,7 +117,9 @@ Afterwards, we can start the applications which immediately connect to the RouDi
 When the application terminates, the runtime cleans up all resources needed for communication with RouDi. This
 includes all memory chunks used for the data transmission which may still be held by the application.
 
-<!-- @todo add overview graphic -->
+Before going into the details in the next section, the following animations depicts the course of events.
+
+![Overview](https://user-images.githubusercontent.com/8661268/74612998-b962bc80-510a-11ea-97f0-62f41c5d287b.gif)
 
 We now briefly define the main entities of an iceoryx system which were partially already used in the example above.
 
@@ -256,7 +258,7 @@ picture below. This is sufficient for simple use cases but inefficient in genera
 latency and wake-ups without data. An alternative approach to receive data is to wait for user-defined events to occur.
 This is provided by our `WaitSet` and `Listener` which are introduced in the following sections.
 
-![Polling alternatives](../images/avoid-polling.svg)
+![Polling alternatives](avoid-polling.svg)
 
 ### WaitSet
 
@@ -298,12 +300,12 @@ For more information about the Listener see our
 ## API
 
 The API is offered in two languages, C++ and C. Detailed information can be found in the
-[C++ example](../examples/icedelivery/) and
-[C example](../examples/icedelivery_in_c/).
+[C++ example](icedelivery.md) and
+[C example](icedelivery_in_c.md).
 
 Many parts of the C++ API follow a functional programming approach which is less error-prone. This requires using
 the monadic types `cxx::expected` and `cxx::optional` which are introduced
-[here](../advanced/how-optional-and-error-values-are-returned-in-iceoryx.md).
+[here](how-optional-and-error-values-are-returned-in-iceoryx.md).
 
 With the C++ API, we distinguish between the `typed API` and the `untyped API`. In the typed API, the underlying
 data type is made apparent by typed pointers or references to some data type T (often a template parameter). This allows

doc/website/getting-started/what-is-iceoryx.md

@@ -11,7 +11,6 @@ consumers of messages. On its own, this is not a new innovation as the approach
 However, iceoryx takes the approach further, ending up in an inter-process-communication technology with a
 publish/subscribe architecture that is fast, flexible and dependable.
 
-
 ## Fast
 
 With the iceoryx API, a publisher can write the message directly into a chunk of memory that was previously requested
@@ -21,11 +20,11 @@ zero-copy — an end-to-end approach from publishers to subscribers without crea
 
 Avoiding the copies on API level is crucial when GBytes of sensor data have to be processed per second on robotics and
 autonomous driving systems. Therefore the iceoryx team contributed to the standardization of true zero-copy capable
-APIs in [ROS 2](https://www.ros.org/) and [AUTOSAR Adaptive](https://www.autosar.org/standards/adaptive-platform/). 
-  
+APIs in [ROS 2](https://www.ros.org/) and [AUTOSAR Adaptive](https://www.autosar.org/standards/adaptive-platform/).
+
 On modern processors iceoryx has a latency of less than 1 µs for transferring a message. And the best message is that
 this latency is constant as size doesn't matter. Want to give it a try? Then have a look at our
-[iceperf example](../examples/iceperf) after having made the first steps. 
+[iceperf example](iceperf.md) after having made the first steps.
 
 ## Flexible
 
@@ -36,13 +35,13 @@ integrating iceoryx as shared memory backbone into a bigger framework.
 
 The APIs support polling access and event-driven interactions with the [Waitset](../overview/#waitset) and
 [Listener](../overview/#listener). Applications can be started and stopped flexibly as there is a service discovery
-behind the scenes that dynamically connects matching communication entities. 
+behind the scenes that dynamically connects matching communication entities.
 
 That iceoryx has the right set of features can be seen from the already existing integrations in middleware and
 frameworks such as [Eclipse Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds),
  [eCAL from Continental](https://continental.github.io/ecal/),
  [RTA-VRTE from ETAS](https://www.etas.com/en/products/rta-vrte.php) and
- [Apex.OS from Apex.AI](https://www.apex.ai/apex-os).  
+ [Apex.Middleware from Apex.AI](https://www.apex.ai/apex-middleware).
 
 ## Dependable
 
@@ -52,13 +51,13 @@ design and implementation of features. The usage of heap, exceptions and any und
 to increase the predictability. Instead a custom memory allocation is being used, based on static memory pools.
 Additionally, the handling of return values and error cases was inspired by upcoming C++ features and other
 languages like Rust (details can be found
-[here](../../advanced/how-optional-and-error-values-are-returned-in-iceoryx/)).
+[here](how-optional-and-error-values-are-returned-in-iceoryx.md)).
 
 As different processes are operating on shared data structures, avoiding deadlocks is becoming all the more important.
 iceoryx uses lock-free data structures like the multi-producer multi-consumer (MPMC) queue that was written portably
-thanks to modern C++.  
+thanks to modern C++.
 
 The tools available for automotive-compliant software development are always one or two releases behind the latest C++
 standard. This fact, combined with our already mentioned constraints, led to a bunch of STL like C++ classes that have
 the goal to combine modern C++ with the reliability needed for the domains iceoryx is used in. They can be found in
-the iceoryx hoofs which are introduced [here](../../advanced/iceoryx_hoofs/)
+the iceoryx hoofs which are introduced [here](iceoryx_hoofs.md).

doc/website/overrides/partials/footer.html

@@ -38,15 +38,15 @@
     {% endif %}
     <div class="md-footer-meta md-typeset">
         <div class="md-footer-meta__inner md-grid">
-            <div class="md-footer-copyright">
+            <div class="md-copyright">
                 Made with
                 <a href="https://squidfunk.github.io/mkdocs-material/" target="_blank" rel="noopener">
                     Material for MkDocs
                 </a>
             </div>
         </div>
         <div class="md-footer-meta__inner md-grid">
-            <div class="md-footer-copyright">
+            <div class="md-copyright">
                 Copyright © 2021 Eclipse Foundation<br>
                 <a href="https://www.eclipse.org/legal/privacy.php" target="_blank">Privacy policy</a><br>
                 <a href="https://www.eclipse.org/legal/termsofuse.php" target="_blank">Terms of use</a><br>
@@ -57,7 +57,7 @@
             </div>
         </div>
         <div class="md-footer-meta__inner md-grid">
-            <div class="md-footer-copyright">
+            <div class="md-copyright">
                 Sponsored by<br>
                 <a href="https://www.eclipse.org/" target="_blank" rel="noopener" title="Eclipse"><img
                         src="{{ base_url }}/images/eclipse-logo.svg" width="100px"></img></a><br>
@@ -68,27 +68,21 @@
             </div>
         </div>
         <div class="md-footer-meta__inner md-grid">
-            <div class="md-footer-social">
+            <div class="md-social">
                 <a href="https://github.com/eclipse-iceoryx/iceoryx" target="_blank" rel="noopener" title="GitHub"
-                    class="md-footer-social__link">
+                    class="md-social__link">
                     {% include ".icons/material/github.svg" %}
                 </a>
-            </div>
-            <div class="md-footer-social">
                 <a href="https://gitter.im/eclipse/iceoryx" target="_blank" rel="noopener" title="Gitter.im Chat"
-                    class="md-footer-social__link">
+                    class="md-social__link">
                     {% include ".icons/material/chat.svg" %}
                 </a>
-            </div>
-            <div class="md-footer-social">
                 <a href="https://github.com/eclipse-iceoryx/iceoryx/blob/master/GOVERNANCE.md#bi-weekly-meetup"
-                    target="_blank" rel="noopener" title="Developer Meetup" class="md-footer-social__link">
+                    target="_blank" rel="noopener" title="Developer Meetup" class="md-social__link">
                     {% include ".icons/material/calendar.svg" %}
                 </a>
-            </div>
-            <div class="md-footer-social">
                 <a href="https://accounts.eclipse.org/mailing-list/iceoryx-dev" target="_blank" rel="noopener"
-                    title="Mailing List" class="md-footer-social__link">
+                    title="Mailing List" class="md-social__link">
                     {% include ".icons/material/email-multiple.svg" %}
                 </a>
             </div>

doc/website/release-notes/.pages

@@ -0,0 +1,6 @@
+nav:
+  - iceoryx-unreleased.md
+  - iceoryx-v2-0-0.md
+  - iceoryx-v1-0-2.md
+  - iceoryx-v1-0-1.md
+  - iceoryx-v1-0-0.md

doc/website/release-notes/iceoryx-unreleased.md

@@ -0,0 +1,27 @@
+# iceoryx vx.x.x
+
+## [vx.x.x](https://github.com/eclipse-iceoryx/iceoryx/tree/vx.x.x) (xxxx-xx-xx)
+
+[Full Changelog](https://github.com/eclipse-iceoryx/iceoryx/compare/vx.x.x...vx.x.x)
+
+**Features:**
+
+**Bugfixes:**
+
+- Foo Bar [\#000](https://github.com/eclipse-iceoryx/iceoryx/issues/000)
+
+**Refactoring:**
+
+**New API features:**
+
+**API Breaking Changes:**
+
+1. Some API change.
+
+    ```cpp
+    // before
+    #include "old/include.hpp"
+
+    // after
+    #include "new/include.hpp"
+    ```