docs(proccess): add versioning and maintenance policy

[leandrodamascena]

Issue number: #3681

Summary

Changes

In this pull request, we are adding a comprehensive guide to inform our customers about our policies regarding the maintenance and versioning of Powertools or AWS Lambda.

User experience

Please share what the user experience looks like before and after this change

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• Meet tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics

Is this a breaking change?

RFC issue number:

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[heitorlessa]

Thank you @leandrodamascena! Starting the editing process.

[heitorlessa]

Pushed the first editing pass. Import notes to discuss on a call as details matter.

---

Significant contract abiding worth reviewing

• No mention of the term semantic versioning
• GA versions minimum support of 2 years (24 months)
  • suggestion: bind to Lambda runtime instead
• At least 6 months announcement for maintenance releases
• Maintenance versions minimum support of 1 year
  • suggestion: given staffing and EOL supply chain, we may not be able to do it.
• End of support versions are kept on GitHub (e.g., v2 branch)
  • suggestion: keep package managers only to prevent higher CI charges on checkout (sparse checkout is possible)
• GA versions support underlying EOL dependencies for at least 6 months
  • suggestion: same issue as maintenance versions for 1yr

Questions

Q: Do we want to keep EOL versions source code on GitHub?

Q: Do we want to support GA releases for a minimum of 2 years?

Q: Are we comfortable supporting underlying EOL dependencies for a minimum of 6 months (e.g., Pydantic v2, Middy 4, etc.)?

Q: Do we want to bundle EOL documentation versions (1.x), keep them (2.32.0)?

[heitorlessa]

Posting update after a call between @leandrodamascena @rubenfonseca and myself.

Answered questions

Q: Do we want to keep EOL versions source code on GitHub?

We will keep as part of the Git tree e.g., tags, commits, etc. We will NOT keep a separate branch for each EOL version e.g., v1.

Q: Do we want to support GA releases for a minimum of 2 years?

Yes, as we've already done so historically.

Q: Are we comfortable supporting underlying EOL dependencies for a minimum of 6 months (e.g., Pydantic v2, Middy 4, etc.)?

No. We wouldn't have the know-how to vendor and backport each 3P critical fix dependency -- it can easily become a supply chain security issue given the plurality of each 3P community.

Q: Do we want to bundle EOL documentation versions (1.x), keep them (2.32.0)?

Keep as-is. Documentation rebuilds are taking approximately 1m10s end-to-end with the new architecture (e.g., S3 over GitHub Pages).

[heitorlessa]

gonna try to meet @am29d @dreamorosi and @hjgraca to hear their thoughts from TS.

[dreamorosi]

Other than the minor comment I've left on the name of one of the 3rd party dependencies, I agree with the document and its content as discussed during the sync.

Great work to all who contributed to its redaction, this will be very useful for both maintainers and customers.

[heitorlessa]

Good to go now @leandrodamascena -- feel free to merge and refresh the latest documentation!

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud