Preparing v1 release (#739)

* Updates to the documentation

* Restricting pulser-core deps to current major

* Updating the setup.py files

* Fix typo in release.md

Co-authored-by: Antoine Cornillot <[email protected]>

---------

Co-authored-by: Antoine Cornillot <[email protected]>

CONTRIBUTING.md

@@ -53,7 +53,7 @@ Here are the steps you should follow to make your contribution:
     git pull upstream develop
     ```
 
-   you will fetch the latest changes in `upstream/develop` and merge them with your working branch, at which point you'll have to solve any merge conflicts that may    arise. This will keep your working branch in sync with `upstream/develop`.
+   you will fetch the latest changes in `upstream/develop` and merge them with your working branch, at which point you'll have to solve any merge conflicts that may arise. This will keep your working branch in sync with `upstream/develop`.
 
 5. Finally, you push your code to your local branch:
 

README.md

@@ -21,8 +21,6 @@ For a comprehensive overview of Pulser, check out [Pulser's white paper](https:/
 
 ## Installation
 
-**Note**: *Pulser v0.6 introduced a split of the ``pulser`` package that prevents it from being correctly upgraded. If you have an older version of ``pulser`` installed and wish to upgrade, make sure to uninstall it first by running ``pip uninstall pulser``.*
-
 To install the latest release of ``pulser``, have Python 3.9 or higher installed, then use ``pip``:
 
 ```bash

docs/source/installation.rst

@@ -1,15 +1,6 @@
 Installation
 ==============
 
-.. warning::
-  Pulser v0.6 introduced a split of the ``pulser`` package that prevents
-  it from being correctly upgraded. If you have an older version of ``pulser`` installed
-  and wish to upgrade, make sure to uninstall it first by running: ::
-
-    pip uninstall pulser
-
-  before proceeding to any of the steps below.
-
 To install the latest release of ``pulser``, have Python 3.9 or higher
 installed, then use ``pip``: ::
 

pulser-core/requirements.txt

@@ -1,6 +1,6 @@
-jsonschema >= 4.17.3
+jsonschema >= 4.17.3, < 5
 referencing
 matplotlib < 4
 # Numpy 1.20 introduces type hints, 1.24.0 breaks matplotlib < 3.6.1
-numpy >= 1.20, != 1.24.0
-scipy
+numpy >= 1.20, != 1.24.0, < 2
+scipy < 2

pulser-core/setup.py

@@ -56,7 +56,7 @@
     python_requires=">=3.9",
     license="Apache 2.0",
     classifiers=[
-        "Development Status :: 3 - Alpha",
+        "Development Status :: 5 - Production/Stable",
         "Programming Language :: Python :: 3",
     ],
     url="https://github.com/pasqal-io/Pulser",

pulser-simulation/setup.py

@@ -56,7 +56,7 @@
     python_requires=">=3.9",
     license="Apache 2.0",
     classifiers=[
-        "Development Status :: 3 - Alpha",
+        "Development Status :: 5 - Production/Stable",
         "Programming Language :: Python :: 3",
     ],
     url="https://github.com/pasqal-io/Pulser",

release.md

@@ -1,29 +1,29 @@
 # Release Procedure
 
-
 ## Versioning
 
-Pulser version follows the [Semantic Versioning 2.0.0 specifcation](https://semver.org/spec/v2.0.0.html), which means its versions are numbered as MAJOR.MINOR.PATCH. 
-
-Currently (as of July 2022), Pulser is still in an early development phase and has a MAJOR of 0 - as such, both breaking and backwards compatible changes and additions to the API will be introduced through increments in the MINOR until version 1.0.0 is released. 
+Pulser version follows the [Semantic Versioning 2.0.0 specifcation](https://semver.org/spec/v2.0.0.html), which means its versions are numbered as MAJOR.MINOR.PATCH.
 
-During this phase, only two type of releases are envisioned:
+According to this specification, three types of releases are envisioned:
 
-- A scheduled release, where the MINOR is bumped and the PATCH is reset (`0.{x}.{y} -> 0.{x+1}.0`)
-- A hotfix, where the PATCH is bumped (`0.{x}.{y} -> 0.{x}.{y+1}`)
+- A major release, where breaking changes may be introduced. Here, the MAJOR is bumped and the MINOR and PATCH are reset (`{x}.{y}.{z} -> {x+1}.0.0`)
+- A minor release, where only the backwards compatible changes are added. Here, the MINOR is bumped and the PATCH is reset (`{x}.{y}.{z} -> {x}.{y+1}.0`).
+- A hotfix, where the PATCH is bumped (`{x}.{y}.{z} -> {x}.{y}.{z+1}`)
 
-Only releases are tracked and tagged in the `master` branch, while development is done in the `develop` branch. To signal this, the version in the `develop` branch should always be one MINOR ahead of `master` and follow the `MAJOR.{MINOR+1}dev{PATCH}` format (e.g. if the latest release tagged in `master` was `0.4.3`, then the version in `develop` should be `0.5dev3`). Through this format, we mark which release is under development and how many patches have occured since its development started (which tells us how many times we brought in changes done directly in `master` through an hotfix).
+Only releases are tracked and tagged in the `master` branch, while development is done in the `develop` branch. To signal this, the version in the `develop` branch should always be one MINOR ahead of `master` and follow the `MAJOR.{MINOR+1}dev{PATCH}` format (e.g. if the latest release tagged in `master` was `1.4.3`, then the version in `develop` should be `1.5dev3`). Through this format, we mark which release is under development and how many patches have occured since its development started (which tells us how many times we brought in changes done directly in `master` through an hotfix).
 
 The version number is centralized in the `VERSION.txt` file and is shared between all the Pulser packages.
 
-
 ## Preparing a scheduled release
 
-A scheduled release is the result of a series of features that were added to the `develop` branch over time. The release process starts out with the creation of a release branch, which should be branched out from `develop` to contain all the desired features and be named `release/v{x}.{y}.{z}`, where `x, y, z` are the MAJOR, MINOR and PATCH of the version to be released (though usually a scheduled release will have PATCH=0). 
+A scheduled release is the result of a series of features that were added to the `develop` branch over time. The release process starts out with the creation of a release branch, which should be branched out from `develop` to contain all the desired features and be named `release/v{x}.{y}.{z}`, where `x, y, z` are the MAJOR, MINOR and PATCH of the version to be released (though usually a scheduled release will have PATCH=0).
 
 In the release branch, no other features can be added. Changes to the documentation and bug fixes are allowed, but should only be done when the development in the `develop` branch needs to continue while the release is being prepared; otherwise, do all the changes in `develop` before checking out the release branch. Note that the release branch will ultimately be *merged* to the `master` branch *without being squashed*, so keep the ammount of commits small and document them well to preserve the quality of the history.
 
-Crucially, the release branch must feature a commit changing the development version in `VERSION.txt` to the desired version of the release. For a minor release, this should be of the form `{x}.{y}dev{z} -> {x}.{y}.0`. 
+Crucially, the release branch must feature a commit changing the development version in `VERSION.txt` to the desired version of the release.
+
+- For a major release: `{x}.{y}dev{z} -> {x+1}.0.0`.
+- For a minor release: `{x}.{y}dev{z} -> {x}.{y}.0`.
 
 Finally, open a PR from the `release/v{x}.{y}.{z}` branch to `master`, have someone review and accept the changes introduced in the release branch (all the changes done in `develop` will be there as well, but those have already been reviewed) and merge the branch to `master` **without squashing the commits**. To keep the `master` branch's history clean and informative, replace Github's default merge commit message with `Release v{x}.{y}.{z}`. Optionally, you can also include a summary of the most important changes introduced in the release.
 
@@ -60,14 +60,14 @@ The release notes should include:
 
 ## Deploying the release
 
-The publication of the release notes will trigger a Github Actions workflow that automatically builds all the packages, publishes them to PyPI and runs some tests to check the publication succeed. 
+The publication of the release notes will trigger a Github Actions workflow that automatically builds all the packages, publishes them to PyPI and runs some tests to check the publication succeed.
 
-Make sure this workflow ran without errors - if not, assess why it failed and, if it was a third-party problem (e.g. a network connection issue), try to rerun the workflow. 
-However, in the unlikely scenario that the deployment failed, it is more likely that there is something that needs to be fixed, in which case you should make an hotfix right away. 
+Make sure this workflow ran without errors - if not, assess why it failed and, if it was a third-party problem (e.g. a network connection issue), try to rerun the workflow.
+However, in the unlikely scenario that the deployment failed, it is more likely that there is something that needs to be fixed, in which case you should make an hotfix right away.
 
 
 ## Merging the changes back to `develop`
 
-Finally, you must open a PR from `master` to `develop` to merge the changes that occured in `master`. In this PR, you must also bump the version you just released, `{x}.{y}.{z}`, to the new development version, `{x}.{y+1}dev{z}` (e.g. `0.8.3 -> 0.9dev3`).
+Finally, you must open a PR from `master` to `develop` to merge the changes that occured in `master`. In this PR, you must also bump the version you just released, `{x}.{y}.{z}`, to the new development version, `{x}.{y+1}dev{z}` (e.g. `1.8.3 -> 1.9dev3`).
 
 Once the PR is accepted, merge it **without squashing** (again, replacing the merge commit message with something more informative) and that's it, you're done!

setup.py

@@ -46,7 +46,7 @@
     python_requires=">=3.9",
     license="Apache 2.0",
     classifiers=[
-        "Development Status :: 3 - Alpha",
+        "Development Status :: 5 - Production/Stable",
         "Programming Language :: Python :: 3",
     ],
     url="https://github.com/pasqal-io/Pulser",