LTS Release Strategy and corresponding changes #3051
Conversation
Signed-off-by: Pradeep Kumar Prakasam <pradeep.prakasam@ontario.ca>
pradeepp88
force-pushed
the
feature/add-LTS-strategy
branch
from
44ca533
to
57e6bfd
Compare
Signed-off-by: Pradeep Kumar Prakasam <pradeep.prakasam@ontario.ca>
pradeepp88
force-pushed
the
feature/add-LTS-strategy
branch
from
57e6bfd
to
f297c47
Compare
Signed-off-by: Pradeep Kumar Prakasam <pradeep.prakasam@ontario.ca>
Signed-off-by: Pradeep Kumar Prakasam <pradeep.prakasam@ontario.ca>
|
@WadeBarnes -- love to get your eyes on this a bit around two specific questions:
Thanks! |
docs/LTS-Strategy.md
Outdated
|
|
||
| Each major release (0.11, 0.12, 0.13 etc.) will eventually have at least one minor release designated by the Aca-py maintainers as the LTS release, e.g. 0.11.1 for 0.11.x, 0.12.2 for 0.12.x (all references to future versions are hypothetical). | ||
|
|
||
| After a LTS release is designated, minor releases will continue as normal. The Aca-py maintainers will decide whether a next release is another minor release, or a new major release. There is no predefined timing for next major version. The decision is typically based on semantic versioning considerations, such as whether API changes are needed or older capabilities need to be removed. Other considerations may also apply, for example significant upgrade steps may motivate a shift to a new major version. |
There was a problem hiding this comment.
Can we assume/declare that patches applied after a LTS release is designated will become the new LTS release? Example: 0.12.1 is designated as LTS, vulnerabilities are found and 0.12.2 is released and becomes the new LTS for that, and so on.
If we don't do this (and maintain multiple branches for an LTS) we will likely get flagged multiple times for the same problem.
There was a problem hiding this comment.
I think the intention is that a minor release — e.g. 0.12 — is the LTS and any patch releases are part of that. So currently we have 0.11 and 0.12 as LTS for the times specified, and the patch releases are part of that.
| branches: | ||
| - 0.12.[0-9]+ | ||
| - 0.11.[0-9]+ |
There was a problem hiding this comment.
Is the idea to keep an active branch for each LTS minor version? Could we have a x.x-lts branch instead that starts at the time a release is designated as LTS and continues until support is dropped?
There was a problem hiding this comment.
Yes, but we still need to have an explicit identifier on each patch.
There was a problem hiding this comment.
We will have a tag for each release we create, so that we can go back to that point at any time. I think that having multiple branches for each minor could cause us to get alerts for old branches for which a newer release has already fixed the vulnerabilities.
There was a problem hiding this comment.
This workflow will kick off only if there is a push to the branch. Example 0.12.2 is released, it will be added to Snyk monitor i.e. new project is created in Synk account.
Once the newer patch version of LTS (ex. 0.12.2) is added to the monitor, older patch version (0.12.1) needs to be removed from monitoring by deleting the project in Snyk account.
There was a problem hiding this comment.
I feel like this might generate operational overhead since we have to track/manage branches in two places (the repo and the Snyk project) - hence the idea of having a -lts branch for the major.minor version designated as such. It would keep being updated for the life of the LTS release, tags will be created for each minor release to have point-in-time traceability and it will only require maintainers to go and delete the project in Snyk (unsure on how to access that at this time) once the LTS status expires.
There was a problem hiding this comment.
There will be exactly one long-lasting branch per LTS minor release, and all of the patch releases will be from that branch. We currently have 0.11.x and 0.12.x branches for the 0.11 and 0.12 LTS, respectively — although we are planning to rename them to 0.11-lts and 0.12-lts. They will be created at the latest patch created at the time we declare it an LTS. So, for example:
- Release a minor version — e.g. 1.0.0
- Wait a bit for it to stabilize — perhaps a 1.0.1, and 1.0.2, or even a 1.1.0
- Declare it LTS and create the “1.1.lts” branch at tag 1.1.0
- 1.1.1 and so on are all on the LTS branch.
As such, the synk yml only needs to be updated when we declare an LTS, and removed when we end of life it.
I think the Snyk approach is good for LTS, as it should catch anything that is in the image and therefore on the related code branch. For the release steps I think they would be the same as for a regular release, except they will be targeting the specified LTS branch. It might be a good idea to create a "maintainer handbook", possibly as we go through the process the first time? |
|
My apologizes for having taken so long to read through this. I think there needs to be some updates to the document to clarify what is meant — particular around release numbering. Here are my comments and suggestions. First, please change the Next up, the confusion about release numbering. Because we have been so slow in getting to Release 1.0.0, we’ve been treating the second and third (the So:
The LTS description needs to be updated to reflect that. In either case, the combination of The declaration of an As per Aries RFC 0799 LTS, the end date for an LTS is defined only when the next LTS is declared and is 9 months after that date. As such, for now, 0.11 is an LTS with a deadline of April 11, 2024 + 9 months, or January 11, 2025. The end date for 0.12 is undefined, as a successor LTS has not been defined. I think in the current PR, the end-dates are calculated as 9 months from the release of the designated LTS vs. from the next LTS. I think more of the material from the Aries RFC could be used in the LTS document. When we declare an LTS (some One thing I’m not sure how best to handle is the tagging of an LTS image. Obviously, it will get the normal @pradeepp88 — do you have time to take a crack at updating the text in the PR to reflect these suggestions? |
Signed-off-by: Pradeep Kumar Prakasam <pradeep.prakasam@ontario.ca>
|
|
I like the wording changes, I think now the document is definitely clearer. I am still thinking about overhead in the management of minor branches in the repo and Snyk - see comment in |
|
|
||
| Current LTS releases: | ||
| - [0.12.x](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.12.1) **Supported upto January 2025** | ||
| - [0.11.x](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.11.1) **Supported upto August 2024** |
There was a problem hiding this comment.
There is currently no defined end date for 0.12.x, and the end date for 0.11.x is January 2025 (9 months after we declared 0.12.x to be LTS).
| - [0.12.x](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.12.1) **Supported upto January 2025** | ||
| - [0.11.x](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.11.1) **Supported upto August 2024** | ||
|
|
||
| Note that the third digit x corresponds to security patches to the LTS releases. |
There was a problem hiding this comment.
Suggest we change the text above to be [0.12-lts] and [0.11-lts] and update this note to say that those are the= names of the branches from which the LTS patch releases are produced.
| Unless specified otherwise, all releases will be upgradable from the prior minor release. | ||
| Additionally, each LTS release is upgradable to the next LTS release. | ||
|
|
||
| Aca-py releases and release notes can be found on the [GitHub releases page](https://github.com/hyperledger/aries-cloudagent-python/releases). |
There was a problem hiding this comment.
Nit-pick, but it should always be “ACA-Py”.
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| This document defines the Long-term support (LTS) release strategy for Hyperledger Aries CloudAgent Python (Aca-Py). This document is inspired from the [Hyperledger Fabric Release Strategy](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md). |
There was a problem hiding this comment.
Same nit-pick — “ACA-Py”, not “Aca-Py” or “Ace-py”.
|
|
||
| ## Release cadence | ||
|
|
||
| Aca-Py will use the pattern of major, minor and patch releases `major.minor.patch` e.g. 0.10.5, 0.11.1, 0.12.0, 0.12.1, 1.0.0, 1.0.1 etc. |
There was a problem hiding this comment.
“uses”, not “will use”. You might want to add a “semver” reference here — https://semver.org/
|
|
||
| ## LTS release cadence | ||
|
|
||
| Because a new major release typically has large new features that may not yet be tried by the user community, and because SDKs may lag in support of the new release, it is not expected that a new major release will immediately be designated as a LTS release, for example, 0.12.1 is not a LTS release. |
There was a problem hiding this comment.
“Major” is the first digit, so change the example to “1.0.0”.
|
|
||
| Because a new major release typically has large new features that may not yet be tried by the user community, and because SDKs may lag in support of the new release, it is not expected that a new major release will immediately be designated as a LTS release, for example, 0.12.1 is not a LTS release. | ||
|
|
||
| Each major release (0.x.x, 1.x.x, 2.x.x etc.) will eventually have at least one minor release designated by the Aca-Py maintainers as the LTS release, e.g. 0.11.x for 0.x.x, 1.1.x for 1.x.x (all references to future versions are hypothetical). |
There was a problem hiding this comment.
Suggested rewording:
From time to time, ACA-Py maintainers will declare that a given major.minor combination will be an LTS release. At that point a branch will be created from the git tag for that release, and series of patch releases will be published as needed to provide long term support. For example, Release 1.1.0 might be declared LTS. A branch 1.1-lts will be created, and patches 1.1.1, 1.1.2, etc. will be published from that branch as needed to meet LTS requirements.
|
|
||
| Each major release (0.x.x, 1.x.x, 2.x.x etc.) will eventually have at least one minor release designated by the Aca-Py maintainers as the LTS release, e.g. 0.11.x for 0.x.x, 1.1.x for 1.x.x (all references to future versions are hypothetical). | ||
|
|
||
| After a LTS release is designated, minor releases will continue as normal. The Aca-Py maintainers will decide whether a next release is another minor release, or a new major release. There is no predefined timing for next major version. The decision is typically based on semantic versioning considerations, such as whether API changes are needed or older capabilities need to be removed. Other considerations may also apply, for example significant upgrade steps may motivate a shift to a new major version. |
There was a problem hiding this comment.
Tweak the sentence to: "After a LTS release is designated, major and minor releases will continue to be published from the ACA-Py main branch."
There was a problem hiding this comment.
I’ve suggested a few more changes that I think clarify the approach.
I think the snyk yml change is needed. We’ve explained the approach, but as I write this, I realize that I’m kind of assuming the processing will be against the repo branch, and not against the container generated from the latest release. As such, I may not be right…
The goal of the snyk scanning is that we be notified of any vulnerability in the last patch for the LTS.
Creating this PR to add the LTS (Long Term Support) Release Strategy for Aca-py releases. This closes #2993
The following are the summary of changes.
4. Supported Features checklist updated with LTS versions