|
7 | 7 |
|
8 | 8 | > A `release` branch for a particular package should only cater to the changes for that package directory. For e.g. the `release/openbb-core-2.0.0` branch should only contain changes for the `openbb-core` package i.e. in the `openbb_platform/core` directory.
|
9 | 9 |
|
| 10 | +### Flow to display only files changes during release cycle in the `release/...` -> `main` PR |
| 11 | + |
| 12 | +1. Merge main into develop before release branch exists, solve any conflict |
| 13 | +2. In the branch `release/…` (before or after publishing) |
| 14 | +3. `git merge main -X ours` (ignore the changes, we brought them in 1.) |
| 15 | +4. `git commit -m "Merge branch 'main' into release/4.2.2"` (empty commit) |
| 16 | + |
| 17 | +### Pre-release checklist |
| 18 | + |
10 | 19 | 1. Open a PR with the changes to be published in the format `release/<version>` (for e.g. `release/4.0.0` ). For a particular package use the format `release/<package>-<version>` (for e.g. `release/openbb-core-1.0.1`).
|
11 | 20 | 2. Ensure all the CI workflows pass.
|
12 | 21 | 3. Ensure all unit tests pass: `pytest openbb_platform -m "not integration"`
|
|
26 | 35 | 1. For the core package run: `python build/pypi/openbb_platform/publish.py --core`
|
27 | 36 | 2. For the extension packages run: `python build/pypi/openbb_platform/publish.py --extensions`
|
28 | 37 | 3. For the `openbb` package - **which requires manual publishing** - do the following
|
29 |
| - 3.1. Bump the dependency package versions |
| 38 | + |
| 39 | + 3.1. Bump the `openbb` package version and the extension versions on `openbb_platform/pyproject.toml` to the latest version. |
| 40 | + |
| 41 | + > [!TIP] |
| 42 | + > Consider using the poetry plugin `up` for updating the extensions to the latest version: |
| 43 | + > 1. `poetry self add poetry-plugin-up` |
| 44 | + > 2. `poetry up --latest` |
30 | 45 |
|
31 | 46 | > [!WARNING]
|
32 | 47 | > Create a new environment before proceeding.
|
33 | 48 | > Make sure that only required extensions are installed
|
34 | 49 |
|
35 | 50 | 3.2. Run `pip install -e .` from `openbb_platform`
|
| 51 | + |
36 | 52 | 3.3. Re-build the static assets that are bundled with the package: `python -c "import openbb; openbb.build()"`
|
37 | 53 | - Run `python -c "import openbb"` after building the static to check that no additional static is being built.
|
38 | 54 | - Run any command to smoke test if the static assets are being built correctly.
|
39 |
| - 3.4. Run unit tests to validate the existence of deprecated endpoints |
| 55 | + |
| 56 | + 3.4. Run unit tests to validate the existence of deprecated endpoints (or watch this through GitHub Actions) |
| 57 | + |
40 | 58 | 3.5. Run `poetry publish --build` from `openbb_platform`
|
| 59 | + |
41 | 60 | 3.6. Run `poetry lock` from `openbb_platform`
|
42 | 61 |
|
43 | 62 | > [!TIP]
|
|
58 | 77 | 4. Open a new PR with the `release/<package>-<version>` branch pointing to the `develop` branch.
|
59 | 78 | 5. Merge the `release/<package>-<version>` branch to the `develop` branch.
|
60 | 79 | 6. If any bugs are encountered, create a new branch - `hotfix` for `main` and `bugfix` for `develop` and merge them accordingly.
|
| 80 | + |
| 81 | +### Generate the changelog |
| 82 | + |
| 83 | +1. Run the changelog automation by using the "release_drafter" GA and passing the number of the previous Release. |
| 84 | +2. Edit and make the changelog live on the repository. |
| 85 | +3. Paste it in the platform-release-changelog Slack channel. |
| 86 | + |
| 87 | +### Publish the CLI |
| 88 | + |
| 89 | +1. Bump `openbb` dependency on `cli/pyproject.toml` to the latest version. |
| 90 | +2. Run `poetry publish --build` from `cli` |
0 commit comments