LTS

[TelegramSam]

No description provided.

[TelegramSam]

Discussed WG 20231108.

Feedback:
don't include LTS in the version tag. Rely on project documentation.
note that version numbering of projects must have a way to indicate patch releases, semver or other.
LTS releases need LTS jump release notes, including gotchas for upgrades.
LTS patches need very clear release notes.
branch created for the LTS to simplify bugfixes.

[TimoGlastra]

I'm not sure if LTS is something that should be documented as part of the Aries RFCs. I see the RFCs mostly as a way to define standards and how to achieve interop. LTS seems something that is specific to each software project, and thus I'd rather see this added to the frameworks that wish to adopt this specific strategy.

[swcurran]

@TimoGlastra — I think the point of this PR is to define/provide guidance on how to do an LTS. The decision to actually add an LTS implementation is indeeed up to the maintainers of the projects. Once that decision is made, this is how to execute on the plan. As such, I think it is appropriate to be included here.

[TheTechmage]

I believe it would be helpful to address Timo's concern within the LTS Support doc, explaining that individual projects may implement their own LTS support some other way. While I understand that individual projects should implement their own LTS policy, I believe it's important to have the idea that an LTS policy should be adopted by all projects as they reach a stage of maturity. As mentioned in the past, having the LTS policy is a huge concern for larger organizations and organizations that just can't move as fast as the ecosystem.

Correct me if I'm wrong, @TelegramSam, but isn't the goal of this RFC to heavily encourage the various Aries projects to adopt an LTS policy, whether they base theirs off of this one or not?

[TelegramSam]

Discussed WG 20240131 No objections to merging.