[skip-changelog] Preparing docs for 1.0.0 release (#2553)

README.md

@@ -10,9 +10,6 @@ and many other tools needed to use any Arduino compatible board and platform fro
 [![Deploy Website status](https://github.com/arduino/arduino-cli/actions/workflows/deploy-cobra-mkdocs-versioned-poetry.yml/badge.svg)](https://github.com/arduino/arduino-cli/actions/workflows/deploy-cobra-mkdocs-versioned-poetry.yml)
 [![Codecov](https://codecov.io/gh/arduino/arduino-cli/branch/master/graph/badge.svg)](https://codecov.io/gh/arduino/arduino-cli)
 
-> **Note:** this software is currently under active development: anything can change at any time, API and UI must be
-> considered unstable until we release version 1.0.0.
-
 ## Docs
 
 For guidance on installation and development, see the [User documentation].

docs/UPGRADING.md

@@ -2,7 +2,7 @@
 
 Here you can find a list of migration guides to handle breaking changes between releases of the CLI.
 
-## 0.36.0
+## 1.0.0
 
 ### Configuration file now supports only YAML format.
 

docs/getting-started.md

@@ -1,5 +1,4 @@
-Despite the lack of feature parity at the moment, Arduino CLI provides many of the features you can find in the Arduino
-IDE. Let's see some examples.
+Arduino CLI provides all the features you can find in the Arduino IDE. Let's see some examples.
 
 ## Before you start
 

docs/versioning.md

@@ -1,21 +1,21 @@
 # Backward compatibility policy for arduino-cli.
 
 The arduino-cli project follows a strict semantic versioning policy. We are committing not to make breaking changes in
-minor releases after the release of version 1.0.0. The project is currently in the last period of the Beta phase.
+minor releases of Arduino CLI 1.x.x.
 
 The release rules are the following:
 
 - Alpha phase `0.0.X`: In this phase, the software is going through a quick iteration of the API, each release (with
   increments of X) may contain massive and breaking changes.
-- **Beta phase `0.Y.X`**: The software is usable, but the API is still not settled and is under continuous testing and
+- Beta phase `0.Y.X`: The software is usable, but the API is still not settled and is under continuous testing and
   review. Breaking changes are expected. Bug fixes and new features are made as patch releases (with increments of X).
   Breaking changes due to API refinements are made as minor releases (with increments of Y).
 - Production release-candidate `1.0.0-rc.X`: in this phase, the software is considered ready for release and distributed
   to the users for final testing. Release candidates (with increments of X) are possible for bug fixes only.
-- Production release `1.Y.X`: For the production releases backward compatibility is guaranteed, and all the breaking
+- **Production release `1.Y.X`**: For the production releases backward compatibility is guaranteed, and all the breaking
   changes are cumulated for the next major release (2.0.0). Bug fixes are made as patch releases (with increments of X);
   New features are released as minor releases (with increments of Y).
-- Next major release development `2.0.0` and up: see below.
+- Next major release development `>=2.0.0` and up: see below.
 
 ## Backward compatibility guarantees and definition of "breaking change"
 
@@ -36,7 +36,7 @@ Changes in the command-line interface are considered breaking if:
 - an optional positional argument or a flag is made mandatory
 - a positional argument or a flag format is changed
 
-The following changes to the command-line syntax are NOT considered breaking:
+The following changes to the command-line syntax are NOT considered breaking changes:
 
 - a new command is added
 - a new optional positional argument is added