|
| 1 | +# How to bump a package version for an existing recipe in ConanCenterIndex? |
| 2 | + |
| 3 | +Once a recipe is approved and merged to ConanCenterIndex, it may need to be updated with new versions released by the upstream. |
| 4 | +When someone needs a new package version that is not available in ConanCenterIndex, that person can open an issue [resquesting a new version](https://github.com/conan-io/conan-center-index/issues/new?assignees=&labels=upstream+update&template=package_upstream_update.yml&title=%5Brequest%5D+%3CLIBRARY-NAME%3E%2F%3CLIBRARY-VERSION%3E). |
| 5 | +Or, by opening a pull request changing and adding that needed version, this is called a `bump version`. |
| 6 | +The [build service](adding_packages/README.md#the-build-service) bumping process is limited to pull requests which **only** adds a new package version and nothing more. Removing older versions, or updating |
| 7 | +the recipe will disqualify a pull request from the `Bump version` [review process](review_process.md) |
| 8 | + |
| 9 | +## Choosing which version should be updated |
| 10 | + |
| 11 | +The first step is checking the version which should be added from the upstream. Please, avoid adding multiple versions which you do not |
| 12 | +need. Adding a new version will increase the building time and storage for each new package configuration. |
| 13 | + |
| 14 | +Once you detect which version should be updated, please, first check if the project `license` keeps the same. |
| 15 | + |
| 16 | +> In case you need to update attributes, dependencies versions, patches, or anything besides the package version in `conandata.yml` and `config.yml`, |
| 17 | + then your pull request will not be classified as bump version. |
| 18 | + |
| 19 | +## What should be modified when bumping a version? |
| 20 | + |
| 21 | +Only the `config.yml` and `conandata.yml` should be updated with that new version: |
| 22 | + |
| 23 | +```yaml |
| 24 | +# config.yml |
| 25 | +versions: |
| 26 | + "1.1.0": <-- New version added. It should be protected by quotes |
| 27 | + folder: all <-- Folder name where conandata.yml is installed |
| 28 | + "1.0.0": |
| 29 | + folder: all |
| 30 | +``` |
| 31 | +
|
| 32 | +```yaml |
| 33 | +# all/conandata.yml |
| 34 | +sources: |
| 35 | + "1.1.0": <-- New version added |
| 36 | + url: "https://example.com/repo/exameple-1.1.0.tar.gz" |
| 37 | + sha256: "b3a24de97a8fdbc835b9833169501030b8977031bcb54b3b3ac13740f846ab30" |
| 38 | + "1.0.0": |
| 39 | + url: "https://example.com/repo/exameple-1.0.0.tar.gz" |
| 40 | + sha256: "91844808532e5ce316b3c010929493c0244f3d37593afd6de04f71821d5136d9" |
| 41 | +``` |
| 42 | +
|
| 43 | +In case a patch should be re-used, it should be present in `conandata.yml` to the specific version as well. |
| 44 | + |
| 45 | +## Reviewing and merging |
| 46 | + |
| 47 | +Bumping version PRs follow the same regular [review process](review_process.md), except for being merged automatically |
| 48 | +as listed on [Labels](labels.md#bump-version) section. |
0 commit comments