chore: touch up workflows and documentation

.github/workflows/generate-docs.yml

@@ -12,7 +12,7 @@ jobs:
       version: ${{ steps.versions.outputs.new_version }}
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
         with:
           fetch-depth: 2
       - id: versions
@@ -33,10 +33,10 @@ jobs:
     name: Generate and Deploy
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
 
       - name: Generate docs
-        uses: mattnotmitt/doxygen-action@v1
+        uses: mattnotmitt/doxygen-action@v1.9
         with:
           working-directory: 'doxygen'
           doxyfile-path: 'doxygen.conf'
@@ -46,9 +46,9 @@ jobs:
         run: |
           mkdir -p doxygen/docs/versions
           sudo mv doxygen/docs/html doxygen/docs/versions/rolling
-          if [ ${{ needs.check-version.outputs.has_changed }} ]; then
-            sudo cp doxygen/docs/versions/rolling doxygen/docs/versions/latest
-            sudo cp doxygen/docs/versions/rolling doxygen/docs/versions/${{ needs.check-version.outputs.version }}
+          if [ ${{ needs.check-version.outputs.has_changed }} = 'true' ]; then
+            sudo cp -r doxygen/docs/versions/rolling doxygen/docs/versions/latest
+            sudo cp -r doxygen/docs/versions/rolling doxygen/docs/versions/${{ needs.check-version.outputs.version }}
           fi
 
       - name: Deploy to documentation branch

CHANGELOG.md

@@ -13,6 +13,7 @@ Release Versions:
 
 ## Upcoming changes (in development)
 
+- chore: touch up workflows and documentation (#181)
 - feat: update demos directory (#179)
 - fix: update copy constructor to avoid warnings (#180)
 - build: remove deprecated Dockerfiles and scripts and update installation instructions (#176)

CONTRIBUTING.md

@@ -1,56 +1,23 @@
 # Contributing
 
-This repository is owned and maintained by AICA SA. We welcome user engagement to find bugs, resolve issues
-and suggest useful features.
+This repository is owned and maintained by [AICA SA](https://www.aica.tech/). We welcome user engagement to find bugs,
+resolve issues and suggest useful features.
 
-Before contributing to this repository, please first discuss the change you wish to make by using the repository
-[Discussions](https://github.com/aica-technology/control-libraries/discussions) or opening an
+Before contributing to this repository, please first discuss the change you wish to make by opening an
 [issue](https://github.com/aica-technology/control-libraries/issues).
 
 When you are ready to contribute,
-[fork the repository and open a Pull Request (PR) from your feature branch](https://docs.github.com/en/get-started/quickstart/contributing-to-projects),
-making sure to **target the `develop` branch of the `aica-technology/control-libraries` repository**.
-Refer to the [PR process](#pull-request-process) section for more information.
+[fork the repository and open a Pull Request (PR) from your feature branch](https://docs.github.com/en/get-started/quickstart/contributing-to-projects). Refer to the [PR process](#pull-request-process) section for more information.
 
 Before the PR can be accepted, contributors who are not employed by AICA must first read and agree to the
 [Contributor License Agreement (CLA)](./licenses/CLA.md), which grants AICA the rights to use, modify and distribute
 open source contributions.
 
 ## Development Environment
 
-Our development and testing workflow uses a Docker container to host the project build dependencies which an IDE then
-accesses remotely via SSH.
-
-The following section describes the configuration steps to use this workflow. Of course, contributors may use whatever
-development environment they prefer, as long as they adhere to the overall contribution guidelines.
-
-### Configuring the development environment
-
-Prerequisites: Install [Docker](https://docs.docker.com/get-docker/)
-and [CLion IDE](https://www.jetbrains.com/clion/download).
-
-Step 1: Build and run the development container server with `./dev-server.sh`. The script requires access to your public
-RSA key file. You may additionally specify a custom port. Run `./dev-server.sh --help` for more details.
-
-Step 2: If not already done,
-[create a remote toolchain in CLion](https://www.jetbrains.com/help/clion/remote-projects-support.html#remote-toolchain)
-using the following credentials:
-
-- Host: `127.0.0.1`
-- Port: `2222` (or custom specified port)
-- User name: `developer`
-- Authentication type: `Key pair`
-
-Step 3: If not already done,
-[create a CMake profile that uses the remote toolchain](https://www.jetbrains.com/help/clion/remote-projects-support.html#CMakeProfile).
-
-Step 4: [Resync the header search paths](https://www.jetbrains.com/help/clion/remote-projects-support.html#resync).
-Repeat this step any time you change the compiler or project dependencies. Optionally you can enable automatic
-synchronization.
-
-Step 5:
-[Select the remote CMake profile](https://www.jetbrains.com/help/clion/remote-projects-support.html#WorkWithRemote)
-to build, run and debug library and test targets entirely with the remote toolchain.
+We provide a [VS Code Dev Containter configuration file](./.devcontainer/devcontainer.json) for development and testing
+in a Docker container. Simply install VS Code and its Dev Container extension and then choose the
+`Dev Containers: Open Folder in Container ...` option from the command palette.
 
 ## Style guide
 
@@ -69,8 +36,9 @@ guide to the testing framework.
 If you are using a properly integrated development environment, you can run and debug the tests for each module locally
 to check the behaviour.
 
-You may also use the script `./build-test.sh` to build the project libraries and run all tests within a Docker
-container. Because this process rebuilds the project from scratch, each evaluation may take several minutes.
+You may also build the `python-test` stage of the main [Dockerfile](./Dockerfile) to build the project libraries and run
+all tests within a Docker container. Because this process rebuilds the project from scratch, each evaluation may take
+several minutes.
 
 ## Pull Request Process
 
@@ -79,33 +47,27 @@ container. Because this process rebuilds the project from scratch, each evaluati
 3. Document the header files and public functions with doxygen comments, and update any relevant README.md
    or documentation files with details of changes to the interface.
 4. Update the [changelog](CHANGELOG.md) with your feature / fix / improvement in the "Upcoming changes" section.
-5. Update the version number using the [update_version.sh](./update_version.sh) script.
-6. Open a pull request into the `develop` branch. Write a meaningful title and description for the PR to make it
+6. Open a pull request into the `main` branch. Write a meaningful title and description for the PR to make it
    clear what changes you have made, why you have made them, and how you have tested the changes.
-7. You may merge the pull request into `develop` once you have the sign-off of one other developer and all CI tests
+7. You may merge the pull request into `main` once you have the sign-off of one other developer and all CI tests
    pass. Always use the "Squash and Merge" option to ensure your changes are contained within a single commit,
    maintaining a linear git history. If unsure, you may request another reviewer to merge it for you.
 
 ## Release strategy
 
-The `main` branch is updated from `develop` at regular release intervals using traditional semantic versioning
-(major.minor.patch).
+All pull requests are merged into `main` using the "Squash and Merge" option. To trigger new releases, the version of
+the project version is increased using traditional semantic versioning (major.minor.patch) at regular intervals.
 
 The major release number should be incremented whenever there is a breaking change to the public API (for example, when
 a previously existing function is deleted or renamed). Minor version numbers contain general new features and
 improvements, while patch numbers represent simple and small fixes.
 
-The `develop` branch is always considered to be a "release candidate" that contains only release-ready code. If, at
-release time, there are features on `develop` that are considered unfinished or broken, they can be marked
+The `main` branch is always considered to be a "release candidate" that contains only release-ready code. If, at
+release time, there are features on `main` that are considered unfinished or broken, they can be marked
 as `EXPERIMENTAL` to exclude them from compilation.
 
-At the time of release, usually when there is minor or major version update, a release branch should be made from
-development.
-
-The release branch should be used to finalize the [changelog](CHANGELOG.md), which includes moving all content from
+At the time of release, usually when there is minor or major version update, a release branch should be made. The
+release branch should be used to finalize the [changelog](CHANGELOG.md), which includes moving all content from
 the "Upcoming changes (in development)" header under a new header with the corresponding release version.
 
-Once the changes specific to the release have been approved, a linear GitFlow strategy is used to merge this release
-branch into `main`, and then additionally squash and rebase the release branch back into `develop`.
-
 The release on `main` should be tagged with the corresponding version as `vX.Y.Z`.

README.md

@@ -1,9 +1,8 @@
-<!-- include general status checks here -->
 <span>
     <img alt="build-release workflow badge" src="https://github.com/aica-technology/control-libraries/actions/workflows/build-release.yml/badge.svg">
     <img alt="build-test workflow badge" src="https://github.com/aica-technology/control-libraries/actions/workflows/build-test.yml/badge.svg?branch=main">
-    <img alt="contribution license agreement workflow badge" src="https://github.com/aica-technology/control-libraries/actions/workflows/check-contribution.yml/badge.svg">
-    <img alt="page build and deployment workflow badge" src="https://github.com/aica-technology/control-libraries/actions/workflows/pages/pages-build-deployment/badge.svg">
+    <img alt="contribution license agreement workflow badge" src="https://github.com/aica-technology/control-libraries/actions/workflows/check-contribution.yml/badge.svg?branch=main">
+    <img alt="page build and deployment workflow badge" src="https://github.com/aica-technology/control-libraries/actions/workflows/generate-docs/badge.svg?branch=main">
 </span>
 
 # Control Libraries

VERSION

@@ -1 +1 @@
-7.3.16
+7.3.17

demos/CMakeLists.txt

@@ -15,7 +15,7 @@ if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
   add_compile_options(-Wall -Wextra -Wpedantic)
 endif()
 
-find_package(control_libraries 7.3.16 CONFIG REQUIRED)
+find_package(control_libraries 7.3.17 CONFIG REQUIRED)
 
 set(DEMOS_SCRIPTS
   task_space_control_loop

doxygen/README.md

@@ -2,8 +2,6 @@
 
 This directory contains configurations for automatic documentation generation using doxygen.
 
-Currently, only documentation for the [source](../source) folder is generated.
-
 ## Manual generation
 
 Use `doxygen doxygen.conf` to generate an html directory in `docs/html`.

doxygen/doxygen.conf

@@ -38,7 +38,7 @@ PROJECT_NAME           = "Control Libraries"
 # could be handy for archiving the generated documentation or if some version
 # control system is used.
 
-PROJECT_NUMBER = 7.3.16
+PROJECT_NUMBER = 7.3.17
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description
 # for a project that appears at the top of each page and should give viewer a

protocol/clproto_cpp/CMakeLists.txt

@@ -1,6 +1,6 @@
 cmake_minimum_required(VERSION 3.15)
 
-project(clproto VERSION 7.3.16)
+project(clproto VERSION 7.3.17)
 
 # Default to C99
 if(NOT CMAKE_C_STANDARD)

python/setup.py

@@ -11,7 +11,7 @@
 # names of the environment variables that define osqp and openrobots include directories
 osqp_path_var = 'OSQP_INCLUDE_DIR'
 
-__version__ = "7.3.16"
+__version__ = "7.3.17"
 __libraries__ = ['state_representation', 'clproto', 'controllers', 'dynamical_systems', 'robot_model']
 __include_dirs__ = ['include']
 

source/CMakeLists.txt

@@ -1,6 +1,6 @@
 cmake_minimum_required(VERSION 3.15)
 
-project(control_libraries VERSION 7.3.16)
+project(control_libraries VERSION 7.3.17)
 
 # Build options
 option(BUILD_TESTING "Build all tests." OFF)