diff --git a/Cargo.toml b/Cargo.toml index ca3d8f41..233bc4f6 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -9,6 +9,7 @@ authors = [ description = "A simple semi-reliable UDP protocol for multiplayer games" keywords = ["gamedev", "networking", "udp", "amethyst"] categories = ["game-engines", "network-programming"] +exclude = ["examples/*", "docs/*", "benches/*"] readme = "README.md" license = "MIT/Apache-2.0" diff --git a/docs/RELEASING.md b/docs/CHANGELOG.md similarity index 59% rename from docs/RELEASING.md rename to docs/CHANGELOG.md index 1d12d36b..c5696d6f 100644 --- a/docs/RELEASING.md +++ b/docs/CHANGELOG.md @@ -1,20 +1,21 @@ -# Release Notes +# Change Log This document contains information about the releases of this crate. -## Version 0.1.0 -The Networking team is happy to announce the release of 0.1.0 of the [laminar crate](https://github.com/amethyst/laminar). +## [0.1.0] - 2018-11-12 +The Networking team is happy to announce the release of `0.1.0`` of the [laminar crate](https://github.com/amethyst/laminar). It provides UDP networking modified for the needs of game networking. Most of the techniques used were published and detailed by [Glenn Fiedler](https://gafferongames.com/). We’d like to extend a special thanks to him and his articles. -**Features** +### Added + - UDP-based protocol - Automatic Fragmentation - RTT estimation -- Connection tracking. -- Unreliable and Reliable sending of packets. -- Protocol version monitoring. +- Connection tracking +- Unreliable and Reliable sending of packets +- Protocol version monitoring - A link conditioner to simulate packet loss and latency -- Good error handling with **zero** panics. +- Good error handling with **zero** panics - Well tested by integration and unit tests -- Benchmarks \ No newline at end of file +- Benchmarks diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 8fc2f82d..de4e16f3 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -3,15 +3,15 @@ As a team, we adopted the following the workflow agreements. When we begin work on the amethyst_network crate, we’ll use the same agreements. They are focused on maintaining a high level of quality in the code, and for working with a highly distributed team. We’re including them here as some of the other teams may find them of use. - All warnings produced by `cargo test` are treated as errors by the CI/CD system -- All 'Clippy' warnings are treated as errors by the CI/CD system -- We use 'Kcov' to track our code coverage; we do not have a required minimum, rather we use this as a potential indicator of issues +- All `clippy` warnings are treated as errors by the CI/CD system +- We use `kcov` to track our code coverage; we do not have a required minimum, rather we use this as a potential indicator of issues - We included sample code about using the library - Setting up a benchmarking framework so we can track regressions - Unit and integration tests, as well as release testing with docker-compose ## Style Guidelines -As a team, we (eventually) agreed on a coherent style for all our work. See this [document](https://github.com/amethyst/laminar/blob/master/docs/StyleGuides) for more information. +As a team, we (eventually) agreed on a coherent style for all our work. See this [document](https://github.com/amethyst/laminar/blob/master/docs/CONTRIBUTING.md#code-style) for more information. Some of the most helpful ones have been: - Keep PRs small, preferably under 200 lines of code when possible @@ -19,8 +19,9 @@ Some of the most helpful ones have been: - You must provide comments for public API - No hard-coded values - No panics nor unwraps in non-test code +- `rustfmt` stable release must be used - `rustfmt` should be done as its own PR, to avoid generating giant PRs that are impossible to review -- We make use of the [forking workflow](https://nl.atlassian.com/git/tutorials/comparing-workflows/forking-workflow). +- We make use of the [forking workflow](https://nl.atlassian.com/git/tutorials/comparing-workflows/forking-workflow) ## Code style @@ -28,18 +29,14 @@ Some code guidelines to keep in mind when contributing to laminar or amethyst-ne 1. Comments - Comment all code you’ve added. Things you should comment: types, methods/functions public fields of structs. - Calculations should be documented. Whether it would be in a PR or code. But it must be clear what is done. - - Public things should get docstring comments using ///. Non-public things may use // comments. - - Keep comments small. - - Don’t create unnecessary comments. They must add value. - - Comments should explain the “why” not the “what”. + - Public things should get docstring comments using `///`. Non-public things may use `//` comments + - Keep comments small + - Don’t create unnecessary comments. They must add value + - Comments should explain the “why” not the “what” 2. Hard Coding - - Don't hard code values anywhere. - - Use the ‘NetworkConfig’ type for common network settings, use consts or parameter input. - - Use of lazy_static is acceptable but first make sure you can’t fix the issue in other ways. + - Don't hard code values anywhere + - Use the ‘NetworkConfig’ type for common network settings, use consts or parameter input + - Use of lazy_static is acceptable but first make sure you can’t fix the issue in other ways 3. Code markup - - Keep files small. Better have small files with small pieces of logic than having one file with 1000 lines of logic with multiple types/structs etc. Note that I speak of logic, tests not included. - - Use ‘rust fmt’ newest version take note to open new PR when doing this. -Don’t run ‘rust fmt’, ‘cargo fix’ during an normal PR because this causes huge PR’s which are not possible to review properly. - - Absolutely no panics/unwraps in the logic. - Follow the error handling pattern elsewhere in the code. - You may have panics/unwraps in test code. + - Keep files small. Better have small files with small pieces of logic than having one file with 1000 lines of logic with multiple types/structs etc. Note that I speak of logic, tests not included + - No panics/unwraps in the main codebase, but they are accepted in tests