chore(release): 3.80.0
What does this MR do?
chore(release): 3.80.0
3.80.0 (2023-08-14)
✨ Features ✨
- add support for DELETE /v2//manifests/ operation (OCI v1.1) (a72ecc0)
- add support for Development Containers media types (352ab6b)
- add support for Falcoctl media types (0694731)
- handlers: add code path to check ongoing rename (6ab5cff)
🐛 Bug Fixes 🐛
- s3: limit multi part upload max layer parts size (8a32ccb)
⚙ ️ Build ⚙ ️
- deps: update module github.com/aws/aws-sdk-go to v1.44.317 (0be1318)
- deps: update module github.com/getsentry/sentry-go to v0.23.0 (f3d1500)
- deps: update module github.com/jackc/pgconn to v1.14.1 (3d23ea3)
- deps: update module github.com/jackc/pgx/v4 to v4.18.1 (087933e)
- deps: update module github.com/jszwec/csvutil to v1.8.0 (427758d)
- deps: update module github.com/prometheus/client_golang to v1.16.0 (77e784c)
- deps: update module github.com/rubenv/sql-migrate to v1.5.2 (57a9a9e)
- deps: update module github.com/stretchr/testify to v1.8.4 (265c146)
- deps: update module go.uber.org/automaxprocs to v1.5.3 (b2142e1)
Related to
Author checklist
-
Feature flags
-
Added feature flag: -
This feature does not require a feature flag
-
-
I added unit tests or they are not required -
I added documentation (or it's not required) -
I followed code review guidelines -
I followed Go Style guidelines -
For ~database changes including schema migrations: -
Manually run up and down migrations in a postgres.ai production database clone and post a screenshot of the result here. -
If adding new queries, extract a query plan from postgres.ai and post the link here. If changing existing queries, also extract a query plan for the current version for comparison. -
Do not include code that depends on the schema migrations in the same commit. Split the MR into two or more.
-
-
Ensured this change is safe to deploy to individual stages in the same environment ( cny
->prod
). State-related changes can be troublesome due to having parts of the fleet processing (possibly related) requests in different ways.
Reviewer checklist
-
Ensure the commit and MR tittle are still accurate. -
If the change contains a breaking change, apply the ~"breaking change" label. -
If the change is considered high risk, apply the label ~high-risk-change -
Identify if the change can be rolled back safely. (note: all other reasons for not being able to rollback will be sufficiently captured by major version changes).
If the MR introduces ~database schema migrations:
-
Ensure the commit and MR tittle start with fix:
,feat:
, orperf:
so that the change appears on the Changelog
If the changes cannot be rolled back follow these steps:
-
If not, apply the label ~"cannot-rollback". -
Add a section to the MR description that includes the following details: -
The reasoning behind why a release containing the presented MR can not be rolled back (e.g. schema migrations or changes to the FS structure) -
Detailed steps to revert/disable a feature introduced by the same change where a migration cannot be rolled back. (note: ideally MRs containing schema migrations should not contain feature changes.) -
Ensure this MR does not add code that depends on these changes that cannot be rolled back.
-