diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c0ac85f5..948906f0 100644 --- a/CONTRIBUTING.md +++ b/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: diff --git a/README.md b/README.md index ac88d54a..378fce86 100644 --- a/README.md +++ b/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 diff --git a/docs/source/installation.rst b/docs/source/installation.rst index 65ea72fd..a587d736 100644 --- a/docs/source/installation.rst +++ b/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``: :: diff --git a/pulser-core/requirements.txt b/pulser-core/requirements.txt index 367a36e0..3b984cc1 100644 --- a/pulser-core/requirements.txt +++ b/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 \ No newline at end of file +numpy >= 1.20, != 1.24.0, < 2 +scipy < 2 \ No newline at end of file diff --git a/pulser-core/setup.py b/pulser-core/setup.py index 4e341933..16433f5a 100644 --- a/pulser-core/setup.py +++ b/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", diff --git a/pulser-simulation/setup.py b/pulser-simulation/setup.py index 5f81b0be..3a6d06bc 100644 --- a/pulser-simulation/setup.py +++ b/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", diff --git a/release.md b/release.md index 591e67b4..a71c0e41 100644 --- a/release.md +++ b/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! \ No newline at end of file diff --git a/setup.py b/setup.py index c99c4b6a..0febb9db 100644 --- a/setup.py +++ b/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",