Transition plan for moving Hyperledger Aries Cloud Agent Python to OpenWallet Foundation acapy

[swcurran]

Latest Update: 2024.10.09

This description will evolve as the transition of ACA-Py into the [OpenWallet Foundation] (OWF) and the transfer of the repo (now done) is made operational. Bookmark this issue to learn about the approach, the progress, the timeline, and guidance on what you should do in updating your deployment to reference the new home for the repository.

Goals/Decisions

• Names used in the repo move to OWF:
  • The new name of this repo is acapy — https://github.com/openwallet-foundation/acapy
    • A rediect is in place so if you use the old Hyperledger repo name, you get to the proper place.
  • The name of the project at OWF is "ACA-Py”, although ACAPY can be used as well. It is not an acronym, or if it is, it is “A Cloud Agent Python”, or in the GNU tradition “ACA-Py is a Cloud Agent Python"
  • The name of the source folder in the repo will be acapy_agent (the name "acapy" is already taken at PyPi).
  • Sub-projects of ACAPY will have repos prefixed by "acapy-", such as acapy-plugins (which has already been moved).
• The documentation site for ACA-Py continues to be the https://aca-py.org, although there might be a bump or two as we complete the post-move updates.
• The description in this issue will be the latest and greatest on the transition, and guidance on updating deployments to reference the new repo and artifacts.
• LTS requirements will be met by continuing to be able to publish 0.11 and 0.12 releases through to their respective end of life dates. That includes being able to push updates to PyPi and GHCR using the existing artifact names. Note that we have not yet declared an LTS 1.x version of the project.

Details

• DONE - None needed. Research if there is a likelihood that we need to do a 0.11 and/or 0.12 LTS release. If so, do it from Hyperledger, before the move.
• Update the README.md for the repo to announce the move and create a file acapy_to_owf.md that will contain updated information about the best practices in updating deployments to the new OWF home of the project/repository.
• Complete release 1.0.1 that contains the current changes to main. This is the last Hyperledger-based release.
  • The update includes a deprecation notice in the README about the Hyperledger repo move to OWF.
  • It also contains a deprecation notices about the movement of the RFC 0160 connections, issue credential v1 and present proof v1 to the plugins repo, removing them from the core ACA-Py repo. That will be done in an upcoming release.
• Before the move prepare PRs that implement the changes resulting from the move to OWF -- but hold off on merging them until after the move. Include documentation updates, GHA changes, and so on.
• Move the repo to OWF.
• Merge the PRs prepared for the move to OWF.
• Add a token to the OWF repo that allows for the publishing of artifacts to the Hyperledger GHCR.
  • Update the GHCR publishing job (GHA) to publish release artifacts to BOTH the OWF and Hyperledger locations.
  • Add a new GHA to publish releases on the 0.11 and 0.12 branches (but not main) to the aries-cloudagent PyPi project.
• Produce a release from OWF (1.1 or 1.1.1) that publishes the artifacts to their new PyPi and old and new GHCR locations.
• Carry on...

[swcurran]

@WadeBarnes and @ryjones -- love to get your input on the plan. Same with new maintainers @thiagoromanos and @ff137, and any other deployers. Does this make it as easy as possible?

For those at the meeting today (@esune @jamshale @dbluhm @mepeltier @PatStLouis) -- note the subtle change I made to the repo that is to be kept at Hyperledger to be able to publish LTS releases. We'll create the fork immediately after the OWF move, but we'll only rename the repo to the current name when we have to publish an LTS release. That will allow the GitHub automatic redirect to work until that point -- which may be forever. 🤞

Feedback welcome!

[WadeBarnes]

• If and when we must do a first 0.11 and/or 0.12 LTS release, we will rename the repo to the old "aries-cloudagent-python" name. At that point the the automatic GitHub redirect to the OWF repo will be stopped. Ideally, we won't ever have to do that, or when we do, the word is out amongst deployers about the change.

I don't think a rename back to aries-cloudagent-python would ever be needed. The artifacts, their names, and where they are published is independent of the name of the repository.

[swcurran]

Awesome! We were thinking that it would be needed for the GHCR namespace. If not — all the better! I’ve updated the plan in the issue description.

[SeanBohan]

Couple of housekeeping issues:

• Mission Statement - LF is going to create a Project Charter for ACA-Py, I am getting that process started. We will a mission statement for the ACA-Py project to be included in the Charter. As this is moving over to the OWF, there is no need for a contribution agreement.

• As ACA-Py is coming into OWF as an Impact project, we will need a representative for the Technical Advisory Council (TAC). The TAC meets every other Weds and should be 2-6 hours per month committment.

• Does the ACA-Py community want to come up with their own logo or should I reach out to LF Marketing for help?

[swcurran]

Thanks, @SeanBohan.

Oh boy, a mission statement. :-). We’ll work on that. Can you direct me to some other Mission Statements of projects so we see the style of what is expected.

We have the bi-weekly ACA-Pug meeting tomorrow and will check in with the community on all three issues.

[jamshale]

One of the trickier things is the LTS. When we fork the openwallet-foundation repo back to hyperledger we'll need to change the name back to aries-cloudagent-python and adjust the github actions to point to hyperledger/aries-cloudagent-python again.

That's all good, but forking won't maintain any of the tags or releases. We'll need to manually create the tags and releases by commit id after forking. The existing images are still available after moving the repo. This is only to create new images and pypi packages.

All the existing github secrets will also be lost. They'll also need to be re-made after forking for publishing workflows.

We should make sure the forked repo no longer allows PR's except from a few users that will create patch releases.

[esune]

We'll need to manually create the tags and releases by commit id after forking. The existing images are still available after moving the repo. This is only to create new images and pypi packages.

Can pypi packages be pushed like it is possible with Docker images? If so, we could just manually push the relevant packages/images to the ghcr for the forked repo - this is only advisable if we expect the LTS releases to be replaced by new ones in the relatively near future and therefore we'd have to manually push only a limited amount of times.

We should make sure the forked repo no longer allows PR's except from a few users that will create patch releases.

+1 to this. Also issue creation (at least from external contributors) should be prevented and redirected to the new repo?

[jamshale]

You can manually publish both the pypi package and the ghrc.io images. For pypi you need the publishing account username/password and for ghrc.io you need a repo PAT with package:read,write,delete privileges.

Getting the github actions to work again and manually tagging the commits wouldn't be too hard with the correct repo rights either, but there is a few steps to do. Renaming the repo again after forking is critical for ghrc because that's how it decides the namespace.

[dbluhm]

I've produced images for a repo where the image name doesn't exactly match the name of the repo. I think the org name must match but the repo name is not required to be in the image name.

[jamshale]

Another thing to consider is changing the project and package name will change the references in plugins. For the managed plugin repo we can do this ourselves but in unmanaged plugins like traction innkeeper they will break if they install the new package without updating the source code.

[swcurran]

I’m hoping this is not an issue:

One of the trickier things is the LTS. When we fork the openwallet-foundation repo back to hyperledger we'll need to change the name back to aries-cloudagent-python and adjust the github actions to point to hyperledger/aries-cloudagent-python again.

The point of moving-and-forking-back before we merge the PRs that we’ve made for the move is that the forked version will not have changed from what was working in Hyperledger before the move. Is that not right? My hope is that the GHAs should still work, except for the repo name change from “aries-cloudagent-python” to “aries-cloudagent-python-lts”.

[jamshale]

I didn't describe this very well. The forking back will work yes if we do it before merging the PR's, but I'm pretty sure we lose the github secrets and the tags/releases after forking back.

The existing artifacts for the releases will still work via redirects but to create new LTS releases via github actions I'm pretty sure we need to recreate the pypi secrets and the tags.

[ryjones]

@jamshale correct. I will ask you all to reconsider any plan to fork it back to Hyperledger.

[swcurran]

We don’t need all the tags — we just need the two (or perhaps 5) we already have, and we know where they belong. Can we not add back or get new secrets? And the tags we need are on branches.

@ryjones — if we don’t have a hyperledger-based repo, how will we produce the needed PyPi and GHCR artifacts for LTS releases. We’re not doing the fork for fun — we think it is necessary.