Tagging this repo

[dbluhm]

The concept of tagging this repo came up on the Aries WG call on Nov. 15, 2023. I wanted to continue that discussion here:

As prior art, consider this text from: https://github.com/hyperledger/aries-acapy-plugin-toolbox#aca-py-version-compatibility

ACA-Py Version Compatibility

To avoid a confusing pseudo-lock-step release, this plugin is versioned independent of ACA-Py. Plugin releases will follow standard semver but each release will also be tagged with a mapping to an ACA-Py version with the format acapy-X.Y.Z-J where X.Y.Z corresponds to the ACA-Py version supported and J is an incrementing number for each new plugin release that targets the same version of ACA-Py.

You should look for the most recent release tagged with the version of ACA-Py you are using (with the highest value for J).

This was a convention that the toolbox plugin adopted (back when we were actively working on it). I think tagging the whole repo will be challenging to do meaningfully; for the toolbox plugin, we needed to keep track changes of the plugin itself as well as the versions of ACA-Py it was compatible with. The plugins should be able to evolve and gain features and be able to version themselves to communicate when new features are added.

[swcurran]

I don’t think tagging will work for this repo, since it consists of multiple components that will be maintained at different rates. Since tags apply across the entire repo, it can never be matched against all plugins and versions of ACA-Py. Each plugin will achieve ACA-Py version compatibility at multiple times.

I think a better approach would be to REQUIRE that all plugins provide a method (such as a YAML file with specific entries) that at minimum contains the version of ACA-Py for which the plugin has been tested. Then, a GHA can generate a human readable list of plugins and the related ACA-Py version each is known to support. The YAML could include other information — name, desciption of the plugin, maintainers, etc.).

[jamshale]

The plugins poetry pyproject.toml file is kind of doing this already. It was the aries-cloudagent and python version that the plugin has been tested. How to use it when trying to pull a version of the plugin though I'm not sure.

I had been thinking that we would keep all the plugins up to date with acapy and that each tag would have release notes with what version of acapy and python it was tested on. This might not be maintainable though. Currently all agents are on the same acapy version 0.11.0.

Not sure what the best thing to do would be but would really like to get this completed and have a reliable way to reference frozen plugins.