From 082db351c0a3fd9e9120b89add10267244898e62 Mon Sep 17 00:00:00 2001 From: Tobin Harding Date: Sat, 16 Jan 2021 08:40:55 +1100 Subject: [PATCH] Remove unexplainable newlines It seems the documentation of this project uses arbitrarily long lines (i.e. no set column width) along with the occasional newline before some sentences (within a paragraph). When to split a sentence onto a newline does not seem to follow any discernible pattern. There are a few instances of newline characters appearing randomly in the middle of a sentence and since, as observed above, there is no fixed column width is use these new lines are out of place. Remove them so the documentation is slightly more uniform and nice to read in an editor. This patch is whitespace only, no other textual changes. --- DEVELOPMENT_CYCLE.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/DEVELOPMENT_CYCLE.md b/DEVELOPMENT_CYCLE.md index ed5cb364..74d730c1 100644 --- a/DEVELOPMENT_CYCLE.md +++ b/DEVELOPMENT_CYCLE.md @@ -1,15 +1,12 @@ # Development Cycle -This project follows a regular releasing schedule similar to the one [used by the Rust language](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). In short, this means that a new release is made at a regular -cadence, with all the feature/bugfixes that made it to `master` in time. This ensures that we don't keep delaying releases waiting for "just one more little thing". +This project follows a regular releasing schedule similar to the one [used by the Rust language](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). In short, this means that a new release is made at a regular cadence, with all the feature/bugfixes that made it to `master` in time. This ensures that we don't keep delaying releases waiting for "just one more little thing". -We decided to maintain a faster release cycle while the library is still in "beta", i.e. before release `1.0.0`: since we are constantly adding new features and, even more importantly, fixing issues, we want developers -to have access to those updates as fast as possible. For this reason we will make a release **every 4 weeks**. +We decided to maintain a faster release cycle while the library is still in "beta", i.e. before release `1.0.0`: since we are constantly adding new features and, even more importantly, fixing issues, we want developers to have access to those updates as fast as possible. For this reason we will make a release **every 4 weeks**. Once the project will have reached a more mature state (>= `1.0.0`), we will very likely switch to longer release cycles of **6 weeks**. -The "feature freeze" will happen **one week before the release date**. This means a new branch will be created originating from the `master` tip at that time, and in that branch we will stop adding new features and only focus -on ensuring the ones we've added are working properly. +The "feature freeze" will happen **one week before the release date**. This means a new branch will be created originating from the `master` tip at that time, and in that branch we will stop adding new features and only focus on ensuring the ones we've added are working properly. ``` master: - - - - * - - - * - - - - - - * - - - * ... @@ -19,8 +16,7 @@ release/0.x.0: * - - # | | release/0.y.0: * - - # ``` -As soon as the release is tagged and published, the `release` branch will be merged back into `master` to update the version in the `Cargo.toml` to apply the new `Cargo.toml` version and all the other fixes made during the feature -freeze window. +As soon as the release is tagged and published, the `release` branch will be merged back into `master` to update the version in the `Cargo.toml` to apply the new `Cargo.toml` version and all the other fixes made during the feature freeze window. ## Making the Release