Prepare for Release 1.0.0 of ACA-Py

[swcurran]

The following is a checklist of items to be completed for Release 1.0.0 of ACA-Py:

• [x] Flag PRs for 1.0.0 (may be merged into 0.12.0)
• [ ] Complete PRs flagged for 1.0.0
• [x] Flag Issues for 1.0.0
• [ ] Complete Issues flagged for 1.0.0
• [ ] Review/discuss/define LTS for ACA-Py, as per RFC 0799 Long Term Support
• [x] From Supported RFCs list as "not completed" for AIP 2.0 RFC 0587 -- Support for the DIDComm V2 envelope format is a work in progress
• [x] Update AIP 2.0 to remove Please Ack
• [ ] Blog Post/Press Release

[ff137]

I'd like to propose a few suggestions to consider for the 1.0.0 release:

• Upgrade Python to 3.12 (I've tested locally and things pass smoothly)
• review TODO / FIXME comments in the codebase ... ideally resolve all of them! But primarily just find all and track important ones.
• In PR tests, there are 296 skipped, and 6 xfailed. Perhaps the skipped tests are worth reviewing and cleaning up where applicable, and perhaps a reinspection of the expected failures too.
• There is a ruff lint rule that's currently being ignored: D417. This rule is for missing arguments in the description of docstrings.
  • This is possibly the most minor of "nice to haves", but there are a lot of methods (281) with missing descriptions, and I feel that this is important enough for maintainability to mention. In an ideal world these can be solved too before a major release.
  • Will require a very patient contributor, possibly with help from GPT / co-pilot to automate some docstrings

Just some thoughts that came to mind! It's very much "nice to have" territory, but probably worth considering some of these before wanting to go maintenance mode.

[WadeBarnes]

I like the idea of upgrading the Python version.

[swcurran]

Thanks @ff137 — @dbluhm @jamshale @ianco and other maintainers, please weigh in on this either/both here and at the next ACA-Pug meeting.

[jamshale]

I'll be taking this over and trying to push the release forward. I like @ff137's suggestions and will be upgrading python and going over todo's and fixme's.

[rngadam]

README.md LTS section is not updated (still referencing 0.12 as Current LTS Release)

[swcurran]

That is correct — 1.0.0 has not yet been named an LTS. We are expecting a 1.0.1 very shortly, and perhaps then we’ll make it an LTS. At that time, the references you indicate will be updated. We probably can just go ahead with that, but we’re still getting used to the LTS process so waiting on a bit more feedback from the community :-).

[rngadam]

That is correct — 1.0.0 has not yet been named an LTS. We are expecting a 1.0.1 very shortly, and perhaps then we’ll make it an LTS. At that time, the references you indicate will be updated. We probably can just go ahead with that, but we’re still getting used to the LTS process so waiting on a bit more feedback from the community :-).

minor vs patch

If I refer to the LTS strategy documentation:

https://github.com/hyperledger/aries-cloudagent-python/blob/693dde06f02da0c7ee9334446b9e0bd07772d9ce/LTS-Strategy.md

Because a new major release typically has large new features that may not yet be tried by the user community, and because deployments may lag in support of the new release, it is not expected that a new major release (such as 1.0.0) will immediately be designated as a LTS release. Eventually, each major release (0.x.x, 1.x.x, 2.x.x etc.) will have at least one minor release designated by the ACA-Py maintainers as an "LTS release."

based on that reading:

• "a minor release" would mean 1.1.0, not 1.0.1
• once declared, LTS would only have PATCH changes (security fixes and user-impacting bugs)

https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

interpretation

(views expressed are my own)

The MAJOR version is where breaking changes are introduced.

Both MINOR and PATCH are backward compatible changes.

For example:

• "Remove deprecated protocols" (#3185) to be done in a MAJOR version as some may still be relying on these protocols.
• I would expect the implementation of did:web, did:indy (#2368, #2369) to be a MINOR bump, as new functionality is introduced that doesn't break anything (BTW, would hope that NotImplemented functionality be done before declaring an LTS release)
• While a logging fix such as issue #3190 would be a PATCH version.

But then, this particular PATCH is not something that we want backported to LTS release. So that means labeling every issue and associated PR requests to be MAJOR, MINOR or PATCH and identifying PATCH as LTS relevant or not.

[swcurran]

Yes, the LTS in this scenario would be “1.0”, with the branch occuring at the 1.0.1 release. The issue is at what point we declare the “LTS”. The maintainers agreed that doing so as a new major release occured would be a bad idea, in case an immediate breaking change occured requiring a 1.1.0 release after LTS was declared for 1.0. So we will wait a bit before the declaration.

Does that description still match your expectations?

[rngadam]

Yes, the LTS in this scenario would be “1.0”, with the branch occuring at the 1.0.1 release. The issue is at what point we declare the “LTS”. The maintainers agreed that doing so as a new major release occured would be a bad idea, in case an immediate breaking change occured requiring a 1.1.0 release after LTS was declared for 1.0. So we will wait a bit before the declaration.

Does that description still match your expectations?

Ah, ok! Yes, I understand now. Waiting for 1.0.1 is just giving an opportunity to find a major issue. If found, we restart the waiting period for the next MINOR and then PATCH bump.