chore: version compatibility docs #1705
Conversation
Signed-off-by: a3hadi <a3hadi@protonmail.com>
Signed-off-by: a3hadi <a3hadi@protonmail.com>
Signed-off-by: a3hadi <a3hadi@protonmail.com>
Signed-off-by: a3hadi <a3hadi@protonmail.com>
Signed-off-by: a3hadi <a3hadi@protonmail.com>
docs/development/releasing.md
Outdated
| 1. Follow the output, push a new tag to the release branch, GitHub actions will automatically build and publish the new release, this will take around 10 minutes. | ||
| 1. Test the new release, make sure everything is running as expected, and then recreate a `stable` tag against the latest release. | ||
| 1. Cherry-pick fixes to the release branch, skip this step if it's the first release in the branch | ||
| 2. Run `make test` to make sure all test cases pass locally |
There was a problem hiding this comment.
Use 1., it will be interpreted correctly.
| @@ -2,21 +2,32 @@ | |||
|
|
|||
| ## Release Branch | |||
|
|
|||
| Always create a release branch for the releases, for example branch `release-0.5` is for all the v0.5.x versions release. If it's a new release branch, simply create a branch from `main`. | |||
| Always create a release branch for the releases. For example branch `release-0.5` is for all the `v0.5.x` version releases. If it's a new release branch, simply create a branch from `main`. | |||
There was a problem hiding this comment.
releasing.md is supposed to be read by contributors/developers, we could mention something like "version mapping needs to be updated at xxx when needed". The real version mapping would be a doc for the users, instead of using a yaml file, it would be better to be in a doc file, maybe shown as a table.
docs/version-mapping.yaml
Outdated
There was a problem hiding this comment.
Since we have this YAML file, can we generate a human friendly table view for docs at build time? Also this YAML can power the manual mapping we maintain in code. There should only be a single source of truth. I am quite certain it will diverge otherwise.
There was a problem hiding this comment.
+1 to use the same YAML for version compatibility check in the code.
There was a problem hiding this comment.
Actually, not that good. Need to carefully think about the process of development and release.
- How to make
mainbranch work (latest). - How to update the file during the release (e.g. add the config for the to be released version).
- How to bring the new config in the release back to
mainbranch.
Details like above need to be addressed.
There was a problem hiding this comment.
I think we need to invest in that, our docs should be versioned based on release.
There was a problem hiding this comment.
I agree, We need to think it through about how to maintain this file with automation.
docs/version-mapping.yaml
Outdated
There was a problem hiding this comment.
+1 to use the same YAML for version compatibility check in the code.
docs/version-mapping.yaml
Outdated
| 1.2.0-rc1: | ||
| - Go: 0.7.0-0 | ||
| - Python: 0.7.0a | ||
| - Java: 0.7.1-0 | ||
| 1.2.0-rc2: | ||
| - Go: 0.7.0-0 | ||
| - Python: 0.7.0a | ||
| - Java: 0.7.1-0 | ||
| 1.2.0-rc3: | ||
| - Go: 0.7.0-0 | ||
| - Python: 0.7.0a | ||
| - Java: 0.7.1-0 | ||
| 1.2.0-rc4: | ||
| - Go: 0.7.0-rc2 | ||
| - Python: 0.7.0a1 | ||
| - Java: 0.7.2-0 |
There was a problem hiding this comment.
Let's rearrange the order so that the latest version is at the top so that it is more relatable to the user.
…umaflow into version-compatibility-docs
Signed-off-by: a3hadi <a3hadi@protonmail.com>
as per #1686