Maintenance: Create a development release versions in pypi

[leandrodamascena]

Why is this needed?

Development releases allow customers to preview upcoming changes in advance. Although these releases should not be used in production, this allows customers to test bug fixes, new features, and other changes in advance.

To add this new package in Pypi, we must follow the Python packaging guide defined here for Development releases: https://packaging.python.org/en/latest/specifications/version-specifiers/#public-version-identifiers

Which area does this relate to?

Automation

Solution

No response

Acknowledgment

• This request meets Powertools for AWS Lambda (Python) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

[heitorlessa]

yup, this would be technically a pre-release in PyPi.

What I love about this is that customers would have to intentionally want to install a pre-release version, allowing bugfixes to land quicker for those who can't wait w/o impacting stability for the majority of customers.

[leandrodamascena]

Assinging to @heitorlessa!
BTW, I prefer to use the .alpha name as suffix.

[heitorlessa]

@leandrodamascena how much of a deal breaker it is if we can't have .alpha suffix? I asked poetry a question as they hard code a suffix: https://github.com/orgs/python-poetry/discussions/9496

If it is, I might need an extra day to think of a non-fragile way of letting Poetry resolve a newer pre-release version, parse it, then replace pyproject.toml and shared/version.py with the .alpha suffix.

Listing out requirements in the meantime shortly

[leandrodamascena]

Let's keep the standard and not complicate things, Heitor.
If they follow the specification, we will also follow and use a. 🚀

[heitorlessa]

Perfect, figured as much.. tks for confirming!

---

List of requirements - lemme know if I missed anything.

• Confirm whether .alpha over poetry default .a is a deal breaker (nope)
• Release every weekday early morning (on-call coverage, no impact to release day)
• Do not touch CHANGELOG (avoid spam, doesn't affect stable release on what's in it)
• PyPi only; do not release a new Lambda Layer (no alias yet, it'd impact versioning)
• Create PR to update pyproject.toml and shared/version.py (ensure deterministic for next release)
• Ensure it doesn't create a new release notes (avoid spam, provenance signing etc)
• Always autoincrement pre-release version (keep it simple over substantial checking for changes, dep/runtime devs etc)
• Run full quality check and test suite
• Do not release docs for each pre-release (develop covers it, avoid dropdown UX issue)
• Allow manual trigger a.k.a dispatch
• Release to PyPi prod, not PyPi test (test pypi maintenance and supply chain differences)
• Do not touch pending-release issues (no post-release prod tasks)

---

Separate PR

• Update docs to tell customers about unstable/prereleases