|
| 1 | +This file claims the rules how Python decide next version number for package. |
| 2 | + |
| 3 | +The package version contains two part: |
| 4 | +1. the package is preview or stable? |
| 5 | +2. version number |
| 6 | + |
| 7 | +# How to judge preview or stable? |
| 8 | +Python SDK is generated with [swagger](https://github.com/Azure/azure-rest-api-specs), so if swagger content is preview, |
| 9 | +the package is preview; if swagger content is stable, the package is stable. |
| 10 | + |
| 11 | +(1) For single api package(for example: [datadog](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/datadog)), |
| 12 | + as long as the current tag is preview, the package version should be preview |
| 13 | + |
| 14 | +(2) For multi api package(for example: [network](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/network/azure-mgmt-network)), |
| 15 | +there will be `DEFAULT_API_VERSION`(for example: [`DEFAULT_API_VERSION` of network](https://github.com/Azure/azure-sdk-for-python/blob/59709af16b7cd29a51d562137bc5bbfdf53f9327/sdk/network/azure-mgmt-network/azure/mgmt/network/_network_management_client.py#L60)). |
| 16 | +As long as it is preview, then the package version is preview. |
| 17 | + |
| 18 | +(note1: If the name of tag contains 'preview' or the tag contains files of 'preview' folder, then the tag is preview tag. |
| 19 | +For exampe: [preview tag](https://github.com/Azure/azure-rest-api-specs/tree/main/specification/compute/resource-manager#tag-package-2021-06-01-preview)) |
| 20 | + |
| 21 | +(note2: If the api-version contains 'preview', then it is preview api-version. for example: [preview api-version](https://github.com/Azure/azure-rest-api-specs/blob/69eacf00a36d565d3220d5dd6f4a5293664f1ae9/specification/network/resource-manager/Microsoft.Network/preview/2015-05-01-preview/network.json#L6)) |
| 22 | + |
| 23 | +(note3: The difference about single api and multi api, please see the detailed file) |
| 24 | + |
| 25 | +(note4: preview package version contains `b`, for example: `1.0.0b1`) |
| 26 | + |
| 27 | +# How to decide next version number |
| 28 | +1\. If current version is preview version, the new tag is preview tag, then next version is `x.x.xbx+1` |
| 29 | + |
| 30 | +2\. If current version is stable version, the new tag is stable tag, then : |
| 31 | + * if there is breaking change, next version is `x+1.x.x` |
| 32 | + * if there is new feature but no breaking change, next version is `x.x+1.x` |
| 33 | + * if there is only bugfix, next version is `x.x.x+1` |
| 34 | + |
| 35 | +3\. If current version is stable version, the new tag is preview tag, calculate version number according to `2` |
| 36 | +and then append `b1` in the result |
| 37 | + |
| 38 | + |
| 39 | +According to the up rules, we could summarize all the possibilities in the following table: |
| 40 | + |
| 41 | + |
| 42 | + |
| 43 | +(`-` means that this item doesn't influence result) |
| 44 | + |
0 commit comments