1.5.0rc0

[swcurran]

New release.

Note that one of the steps I do in a release is update references to the ACA-Py version to the new version (e.g. change "1.4.0" to "1.5.0") in places where it makes sense. In this release I see that there are a number of new instances of places releases are mentioned. Notes and questions:

• The "Container Image" tagging is now documented (yay!) in two places (boo!) -- publishing.md and in docs/deploying/containerimages... OK to remove the one in Publishing?
• The "Container Image" tagging uses the form "1.5.0-rc0" in the documentation, even though in GitHub we are using "1.5.0rc0" -- does the GHCR tagging match the GitHub tagging or is the "-" inserted? @WadeBarnes
• The Dockerfiles that reference the "current" ACA-Py version do not get updated until after the release is complete. Does that rule remain the same?
• The new "Plugin Installer" references the "current" ACA-Py version (1.4.0), and I did not change those references -- assuming they are to be handled like the Dockerfiles. I assume that is correct as well?

I noted substantial changes in the OpenAPI.json file that I think are to be expected based on the removal of the AIP 1.0 protocols, but please verify.

Thanks!

[jamshale]

I think the one failing integration test may be an intermittent issue with the ledger, but it is somewhat related to the anoncreds upgrade which had changes. If it fails again I'll have a closer look.

[jamshale]

I think this failing test is related to the cred_def creation endpoint not waiting for the rev_reg to be fully created before returning a response. We saw a failing test in the webvh plugin because of this.

I doubt it is a real issue. I'll try and fix it by tomorrow.

[ff137]

Just a note that this should maybe be 1.5.0rc0

also re:

"Container Image" tagging uses the form "1.5.0-rc0"

I believe that the hyphen is required for official semantic versioning, whereas python convention doesn't require the hyphen and drops it for python versioning

[esune]

The documentation discrepancy may originate from me updating the docs and using strict semantic versioning as @ff137 noted. I think we can either update the docs and keep tagging with the pattern we used so far (I don;t think the new publish action would complain), or deploy docker images using stricter semantic versioning, but that would cause discrepancies.

However, if PUBLISHING.md is used as a step-by-step guide to release it might be worth leaving some information to check the tagging process was successful and proceeded as expected?

[swcurran]

The question is really what those instances of versions refer to and precisely what is the format of each instance of "version". If they refer to GitHub or PyPi tags, then they need to be fixed. If (as I assume from the context) they refer to GHCR container image tags, then they need to be verified that the "-" is really present -- which is what I was asking.

[ff137]

I think this failing test is related to the cred_def creation endpoint not waiting for the rev_reg to be fully created before returning a response. We saw a failing test in the webvh plugin because of this.

I doubt it is a real issue. I'll try and fix it by tomorrow.

That was one of the bugs I tried to resolve in the #3690 changes (event bus no longer being synchronous). It could be that the default REVOCATION_REGISTRY_CREATION_TIMEOUT variable should be greater than the current 60s, if a slow ledger means it can take longer than that

[esune]

This was meant to use generic versions to avoid having to update this file with every release, since it is just documentation. If we want to keep it aligned with the latest released version this is fine, but thought to point it out.

[swcurran]

Understood. Part of the publishing process (documented in PUBLISHING.md) is to find all of the references to the version to both change because they must (e.g. pyproject.toml) or should (SupportedRFCs.md) or to see if they are still accurate (e.g. LTS versions, etc.). The list was pretty small up to now so easy. These additions just add more and so I've got to decide if it is useful to keep them up to date so we can decide per release if they are still relevant. Probably not is my leaning.

[sonarqubecloud]

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 SonarQube Cloud

[jamshale]

Interestingly this failing BDD test is passing for me locally. However, it really shouldn't be a 500 error. It might just require a longer wait for the registry to be created. I think we can go ahead and merge this and maybe I can get it fixed for the official release.