Skip to content

Commit

Permalink
Adjustments following review
Browse files Browse the repository at this point in the history
  • Loading branch information
@mprazz
mprazz committed Nov 17, 2020
1 parent a55f179 commit 1322e1b
Showing 1 changed file with 35 additions and 38 deletions.
73 changes: 35 additions & 38 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -202,35 +202,6 @@ Just execute this command to resolve merge conflicts in `poetry.lock` automatica
poetry-merge-lock
```

### Steps to release a new version
Releasing a new version is quite simple, as the packages are build and distributed by GitHub Actions.

*Terminology*:
* patch release (third version part increases): 1.1.2 -> 1.1.3
* minor release (second version part increases): 1.1.3 -> 1.2.0
* major release (first version part increases): 1.2.0 -> 2.0.0

*Release steps*:
1. Make sure all dependencies are up to date (**especially Rasa SDK**)
- For Rasa SDK that means first creating a [new Rasa SDK release](https://github.com/RasaHQ/rasa-sdk#steps-to-release-a-new-version) (make sure the version numbers between the new Rasa and Rasa SDK releases match)
- Once the tag with the new Rasa SDK release is pushed and the package appears on [pypi](https://pypi.org/project/rasa-sdk/), the dependency in the rasa repository can be resolved (see below).
2. Switch to the branch you want to cut the release from (`master` in case of a major / minor, the current feature branch for patch releases)
- Update the `rasa-sdk` entry in `pyproject.toml` with the new release version and run `poetry update`. This creates a new `poetry.lock` file with all dependencies resolved.
- Commit the changes with `git commit -am "bump rasa-sdk dependency"` but do not push them. They will be automatically picked up by the following step.
3. Run `make release`
4. Create a PR against master or the release branch (e.g. `1.2.x`)
5. Once your PR is merged, tag a new release (this SHOULD always happen on master or release branches), e.g. using
```bash
git tag 1.2.0 -m "next release"
git push origin 1.2.0
```
GitHub will build this tag and push a package to [pypi](https://pypi.python.org/pypi/rasa)
6. **If this is a minor release**, a new release branch should be created pointing to the same commit as the tag to allow for future patch releases, e.g.
```bash
git checkout -b 1.2.x
git push origin 1.2.x
```

### Code Style

To ensure a standardized code style we use the formatter [black](https://github.com/ambv/black).
Expand Down Expand Up @@ -266,7 +237,7 @@ We host the site on netlify. On master branch builds (see `.github/workflows/doc
the `documentation` branch. Netlify automatically re-deploys the docs pages whenever there is a change to that branch.

## Releases
### Release Timeline
### Release Timeline for minor releases
**For Rasa Open Source, we usually commit to time-based releases, specifically on a monthly basis.**
This means that we commit beforehand to releasing a specific version of Rasa Open Source on a specific day,
and we cannot be 100% sure what will go in a release, because certain features may not be ready.
Expand All @@ -288,7 +259,7 @@ be in, but it's useful to take a moment to evaluate what's assigned to the miles
release, as well as:
1. Providing the link to the appropriate milestone
2. Reminding everyone to go over their issues and PRs and please assign them to the milestone
3. Clarifying the scheduled date for the release
3. Reminding everyone of the scheduled date for the release

#### Release day! 🚀

Expand All @@ -297,26 +268,52 @@ the release, and the time you're aiming to start releasing (again, no later than
cause delays)
2. **Go over the milestone and evaluate the status of any PR merging that's happening. Follow up with people on their
bugs and fixes.** If the release introduces new bugs or regressions that can't be fixed in time, we should discuss on
Slack about this and take a decision to go forward or postpone the release.
Slack about this and take a decision to go forward or postpone the release. The PR / issue owners are responsible for
communicating any issues which might be release relevant.
3. Once everything in the milestone is taken care of, post a small message on Slack communicating you are about to
start the release process (in case anything is missing).
4. **You may now do the release by following the instructions outlined in the
[Rasa Open Source README](#steps-to-release-a-new-version) !**

### Cutting a Micro release
### Steps to release a new version
Releasing a new version is quite simple, as the packages are build and distributed by GitHub Actions.

*Terminology*:
* patch release (third version part increases): 1.1.2 -> 1.1.3
* minor release (second version part increases): 1.1.3 -> 1.2.0
* major release (first version part increases): 1.2.0 -> 2.0.0

Micro releases are simpler to cut, since:
*Release steps*:
1. Make sure all dependencies are up to date (**especially Rasa SDK**)
- For Rasa SDK that means first creating a [new Rasa SDK release](https://github.com/RasaHQ/rasa-sdk#steps-to-release-a-new-version) (make sure the version numbers between the new Rasa and Rasa SDK releases match)
- Once the tag with the new Rasa SDK release is pushed and the package appears on [pypi](https://pypi.org/project/rasa-sdk/), the dependency in the rasa repository can be resolved (see below).
2. Switch to the branch you want to cut the release from (`master` in case of a major / minor, the current feature branch for patch releases)
- Update the `rasa-sdk` entry in `pyproject.toml` with the new release version and run `poetry update`. This creates a new `poetry.lock` file with all dependencies resolved.
- Commit the changes with `git commit -am "bump rasa-sdk dependency"` but do not push them. They will be automatically picked up by the following step.
3. Run `make release`
4. Create a PR against master or the release branch (e.g. `1.2.x`)
5. Once your PR is merged, tag a new release (this SHOULD always happen on master or release branches), e.g. using
```bash
git tag 1.2.0 -m "next release"
git push origin 1.2.0
```
GitHub will build this tag and push a package to [pypi](https://pypi.python.org/pypi/rasa)
6. **If this is a minor release**, a new release branch should be created pointing to the same commit as the tag to allow for future patch releases, e.g.
```bash
git checkout -b 1.2.x
git push origin 1.2.x
```

### Cutting a Micro release

- They are meant to contain only bugfixes
- They require no code freeze
- They require no general QA pass
Micro releases are simpler to cut, since they are meant to contain only bugfixes.

**The only things you need to do to cut a micro are:**

1. Notify the engineering team on Slack that you are planning to cut a micro, in case someone has an important fix
to add.
2. Make sure the bugfix(es) are in the release branch you will use (p.e if you are cutting a `2.0.4` micro, you will
need your fixes to be on the `2.0.x` release branch)
need your fixes to be on the `2.0.x` release branch). All micros must come from a `.x` branch!
3. Once you're ready to release the Rasa Open Source micro, checkout the branch, run `make release` and follow the
steps + get the PR merged.
4. Once the PR is in, pull the `.x` branch again and push the tag!
Expand Down

0 comments on commit 1322e1b

Please sign in to comment.