LTS Release Strategy and corresponding changes

[pradeepp88]

Creating this PR to add the LTS (Long Term Support) Release Strategy for Aca-py releases. This closes https://github.com/hyperledger/aries-cloudagent-python/issues/2993

The following are the summary of changes.

1. Releases section added to Readme
2. LTS Release Strategy document added to docs
3. Snyk container image scanning mode changed to 'monitor' for LTS images
4. Supported Features checklist updated with LTS versions

[swcurran]

@WadeBarnes -- love to get your eyes on this a bit around two specific questions:

• Are you happy with the Snyk approach to scanning images (which I think is the plan) for the security vulnerabilities that we have to be able to patch in LTS versions of ACA-Py? My question is about whether that gets us the dependabot style dependencies that we would get from source code scanning. I'm assuming so, but don't understand this well enough that I can confirm it for myself.
• Is there sufficient guidance on the mechanics of releasing a patch -- e.g. easy enough that I can follow it...

Thanks!

[esune]

@WadeBarnes -- love to get your eyes on this a bit around two specific questions:

* Are you happy with the Snyk approach to scanning images (which I think is the plan) for the security vulnerabilities that we have to be able to patch in LTS versions of ACA-Py?  My question is about whether that gets us the `dependabot` style dependencies that we would get from source code scanning.  I'm assuming so, but don't understand this well enough that I can confirm it for myself.

* Is there sufficient guidance on the mechanics of releasing a patch -- e.g. easy enough that I can follow it...

Thanks!

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?

[swcurran]

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 Aca-pys to ACA-Py in the PR 😄 .

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 y and z in the semver x.y.z numbering scheme) as major and minor releases instead of what they should be — minor and patch. That is not inadvertent, particularly as it relates to LTS, and will not continue past the 1.0.0 release. Going forward, we will use proper x.y.z for proper major.minor.patch. From time-to-time, we will declare a certain x.y release as an LTS, and will release as needed z patches for the LTS.

So:

• For prior to 1.0.0, a change in the minor release number has served as a breaking change indicator.
• From 1.0.0 on, the major release number will serve as the breaking change indicator.

The LTS description needs to be updated to reflect that.

In either case, the combination of x.y (major.minor) will be used when designating an LTS, and all of the patches (zs) based on those numbers will be for the purpose of LTS releases. I would expect that pretty much any release that is NOT an LTS patch will trigger a minor (y) update.

The declaration of an x.y combination should be in the README.md.

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 x.y.0), we will create a branch at that point (labelled, presumably x.y or maybe x.yLTS), and that is what will be monitored for vulnerabilities going forward. We’ll PR or apply cherry-picked PRs to that branch and then do the patch releases from there using the normal release process.

One thing I’m not sure how best to handle is the tagging of an LTS image. Obviously, it will get the normal x.y.z tag, but is it also possible to publish docker images with an “LTS” tag that moves (like “latest”) along the path of any LTS release?

@pradeepp88 — do you have time to take a crack at updating the text in the PR to reflect these suggestions?

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[pradeepp88]

Updated the LTS Strategy document with updates. @swcurran @esune please review.

[esune]

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 snyk-lts.yml

[swcurran]

@pradeepp88 -- we really need this completed urgently. Can you make the changes? Or are you OK with me grabbing the files and putting them into my own PR? You should get the credit, so wouldn't normally ask, but we really need this PR merged very soon!

Thanks

[swcurran]

Closing this as replaced by #3143 that used the changes from this PR as the basis for that one. We just can't wait to get the updates into this PR. Thanks for pushing this issue, @pradeepp88 --- sorry we couldn't wait on your PR.