|
1 | 1 | # Unified Runtime
|
2 | 2 |
|
3 |
| -[](https://github.com/oneapi-src/unified-runtime/actions/workflows/cmake.yml) |
| 3 | +[](https://github.com/intel/llvm/actions/workflows/ur-precommit.yml) |
4 | 4 | [](https://github.com/oneapi-src/unified-runtime/actions/workflows/nightly.yml)
|
5 | 5 | [](https://github.com/oneapi-src/unified-runtime/actions/workflows/docs.yml)
|
6 | 6 | [](https://github.com/oneapi-src/unified-runtime/actions/workflows/benchmarks-nightly.yml)
|
@@ -60,14 +60,6 @@ add_executable(example example.cpp)
|
60 | 60 | target_link_libraries(example PUBLIC unified-runtime::headers)
|
61 | 61 | ```
|
62 | 62 |
|
63 |
| -### Weekly tags |
64 |
| - |
65 |
| -Each Friday at 23:00 UTC time a [prerelease |
66 |
| -tag](https://github.com/oneapi-src/unified-runtime/releases) is created which |
67 |
| -takes the form `weekly-YYYY-MM-DD`. These tags should be used by downstream |
68 |
| -projects which intend to track development closely but maintain a fixed point in |
69 |
| -history to avoid pulling potentially breaking changes from the `main` branch. |
70 |
| - |
71 | 63 | ## Third-Party tools
|
72 | 64 |
|
73 | 65 | The recommended method to install the third-party tools is using a Python
|
@@ -207,26 +199,3 @@ Code is generated using included [Python scripts](/scripts/README.md).
|
207 | 199 |
|
208 | 200 | Documentation is generated from source code using Sphinx -
|
209 | 201 | see [scripts dir](/scripts/README.md) for details.
|
210 |
| - |
211 |
| -## Release Process |
212 |
| - |
213 |
| -Unified Runtime releases are aligned with oneAPI releases. Once all changes |
214 |
| -planned for a release have been accepted, the release process is defined as: |
215 |
| - |
216 |
| -1. Create a new release branch based on the [main][main-branch] branch taking |
217 |
| - the form `v<major>.<minor>.x` where `x` is a placeholder for the patch |
218 |
| - version. This branch will always contain the latest patch version for a given |
219 |
| - release. |
220 |
| -2. Create a PR to increment the CMake project version on the [main][main-branch] |
221 |
| - and merge before accepting any other changes. |
222 |
| -3. Create a new tag based on the latest commit on the release branch taking the |
223 |
| - form `v<major>.<minor>.<patch>`. |
224 |
| -4. Create a [new GitHub release][new-github-release] using the tag created in |
225 |
| - the previous step. |
226 |
| - * Prior to version 1.0, check the *Set as a pre-release* tick box. |
227 |
| -5. Update downstream projects to utilize the release tag. If any issues arise |
228 |
| - from integration, apply any necessary hot fixes to `v<major>.<minor>.x` |
229 |
| - branch and go back to step 3. |
230 |
| - |
231 |
| -[main-branch]: https://github.com/oneapi-src/unified-runtime/tree/main |
232 |
| -[new-github-release]: https://github.com/oneapi-src/unified-runtime/releases/new |
0 commit comments