Closed swcurran closed 1 month ago
I'd like to propose a few suggestions to consider for the 1.0.0 release:
D417
. This rule is for missing arguments in the description of 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.
I like the idea of upgrading the Python version.
Thanks @ff137 — @dbluhm @jamshale @ianco and other maintainers, please weigh in on this either/both here and at the next ACA-Pug meeting.
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.
README.md LTS section is not updated (still referencing 0.12 as Current LTS Release)
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 :-).
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 :-).
If I refer to the LTS strategy documentation:
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:
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.
(views expressed are my own)
The MAJOR version is where breaking changes are introduced.
Both MINOR and PATCH are backward compatible changes.
For example:
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.
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?
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.
The following is a checklist of items to be completed for Release 1.0.0 of ACA-Py:
RFC 0587 -- Support for the DIDComm V2 envelope format is a work in progress
Please Ack