Mu-L · pull · Jun 5, 2025 · Mar 31, 2025 · Mar 31, 2025 · Apr 1, 2025
diff --git a/.github/workflows/go-cross.yml b/.github/workflows/go-cross.yml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
     steps:
       - uses: actions/checkout@v4

diff --git a/.github/workflows/go-fips.yml b/.github/workflows/go-fips.yml
diff --git a/.github/workflows/go-healing.yml b/.github/workflows/go-healing.yml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
     steps:
       - uses: actions/checkout@v4

diff --git a/.github/workflows/go-lint.yml b/.github/workflows/go-lint.yml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
     steps:
       - uses: actions/checkout@v4

diff --git a/.github/workflows/go-resiliency.yml b/.github/workflows/go-resiliency.yml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
     steps:
       - uses: actions/checkout@v4

diff --git a/.github/workflows/go.yml b/.github/workflows/go.yml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
     steps:
       - uses: actions/checkout@v4

diff --git a/.github/workflows/iam-integrations.yaml b/.github/workflows/iam-integrations.yaml
@@ -61,7 +61,7 @@ jobs:
       # are turned off - i.e. if ldap="", then ldap server is not enabled for
       # the tests.
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         ldap: ["", "localhost:389"]
         etcd: ["", "http://localhost:2379"]
         openid: ["", "http://127.0.0.1:5556/dex"]

diff --git a/.github/workflows/mint.yml b/.github/workflows/mint.yml
@@ -29,7 +29,7 @@ jobs:
       - name: setup-go-step
         uses: actions/setup-go@v5
         with:
-          go-version: 1.23.x
+          go-version: 1.24.x
 
       - name: github sha short
         id: vars

diff --git a/.github/workflows/replication.yaml b/.github/workflows/replication.yaml
@@ -21,7 +21,7 @@ jobs:
 
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
 
     steps:
       - uses: actions/checkout@v4

diff --git a/.github/workflows/root-disable.yml b/.github/workflows/root-disable.yml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
 
     steps:

diff --git a/.github/workflows/upgrade-ci-cd.yaml b/.github/workflows/upgrade-ci-cd.yaml
@@ -20,7 +20,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     strategy:
       matrix:
-        go-version: [1.23.x]
+        go-version: [1.24.x]
         os: [ubuntu-latest]
 
     steps:

diff --git a/.github/workflows/vulncheck.yml b/.github/workflows/vulncheck.yml
@@ -21,7 +21,8 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v5
         with:
-          go-version: 1.23.5
+          go-version: 1.24.x
+          cached: false
       - name: Get official govulncheck
         run: go install golang.org/x/vuln/cmd/govulncheck@latest
         shell: bash

diff --git a/.typos.toml b/.typos.toml
@@ -14,6 +14,7 @@ extend-ignore-re = [
     'http\.Header\{"X-Amz-Server-Side-Encryptio":',
     "ZoEoZdLlzVbOlT9rbhD7ZN7TLyiYXSAlB79uGEge",
     "ERRO:",
+    "(?Rm)^.*(#|//)\\s*spellchecker:disable-line$", # ignore line
 ]
 
 [default.extend-words]

diff --git a/Dockerfile.hotfix b/Dockerfile.hotfix
@@ -1,4 +1,4 @@
-FROM golang:1.23-alpine as build
+FROM golang:1.24-alpine as build
 
 ARG TARGETARCH
 ARG RELEASE

diff --git a/Dockerfile.release b/Dockerfile.release
@@ -1,4 +1,4 @@
-FROM golang:1.23-alpine AS build
+FROM golang:1.24-alpine AS build
 
 ARG TARGETARCH
 ARG RELEASE

diff --git a/Dockerfile.release.old_cpu b/Dockerfile.release.old_cpu
@@ -1,4 +1,4 @@
-FROM golang:1.23-alpine AS build
+FROM golang:1.24-alpine AS build
 
 ARG TARGETARCH
 ARG RELEASE

diff --git a/Makefile b/Makefile
@@ -24,8 +24,6 @@ help: ## print this help
 getdeps: ## fetch necessary dependencies
 	@mkdir -p ${GOPATH}/bin
 	@echo "Installing golangci-lint" && curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(GOLANGCI_DIR)
-	@echo "Installing msgp" && go install -v github.com/tinylib/[email protected]
-	@echo "Installing stringer" && go install -v golang.org/x/tools/cmd/stringer@latest
 
 crosscompile: ## cross compile minio
 	@(env bash $(PWD)/buildscripts/cross-compile.sh)
@@ -188,9 +186,9 @@ hotfix-vars:
 	$(eval VERSION := $(shell git describe --tags --abbrev=0).hotfix.$(shell git rev-parse --short HEAD))
 
 hotfix: hotfix-vars clean install ## builds minio binary with hotfix tags
-	@wget -q -c https://github.com/minio/pkger/releases/download/v2.3.10/pkger_2.3.10_linux_amd64.deb
-	@wget -q -c https://raw.githubusercontent.com/minio/minio-service/v1.1.0/linux-systemd/distributed/minio.service
-	@sudo apt install ./pkger_2.3.10_linux_amd64.deb --yes
+	@wget -q -c https://github.com/minio/pkger/releases/download/v2.3.11/pkger_2.3.11_linux_amd64.deb
+	@wget -q -c https://raw.githubusercontent.com/minio/minio-service/v1.1.1/linux-systemd/distributed/minio.service
+	@sudo apt install ./pkger_2.3.11_linux_amd64.deb --yes
 	@mkdir -p minio-release/$(GOOS)-$(GOARCH)/archive
 	@cp -af ./minio minio-release/$(GOOS)-$(GOARCH)/minio
 	@cp -af ./minio minio-release/$(GOOS)-$(GOARCH)/minio.$(VERSION)

diff --git a/PULL_REQUESTS_ETIQUETTE.md b/PULL_REQUESTS_ETIQUETTE.md
@@ -0,0 +1,93 @@
+# MinIO Pull Request Guidelines
+
+These guidelines ensure high-quality commits in MinIO’s GitHub repositories, maintaining 
+a clear, valuable commit history for our open-source projects. They apply to all contributors, 
+fostering efficient reviews and robust code.
+
+## Why Pull Requests?
+
+Pull Requests (PRs) drive quality in MinIO’s codebase by:
+- Enabling peer review without pair programming.
+- Documenting changes for future reference.
+- Ensuring commits tell a clear story of development.
+
+**A poor commit lasts forever, even if code is refactored.**
+
+## Crafting a Quality PR
+
+A strong MinIO PR:
+- Delivers a complete, valuable change (feature, bug fix, or improvement).
+- Has a concise title (e.g., `[S3] Fix bucket policy parsing #1234`) and a summary with context, referencing issues (e.g., `#1234`).
+- Contains well-written, logical commits explaining *why* changes were made (e.g., “Add S3 bucket tagging support so that users can organize resources efficiently”).
+- Is small, focused, and easy to review—ideally one commit, unless multiple commits better narrate complex work.
+- Adheres to MinIO’s coding standards (e.g., Go style, error handling, testing).
+
+PRs must flow smoothly through review to reach production. Large PRs should be split into smaller, manageable ones.
+
+## Submitting PRs
+
+1. **Title and Summary**:
+   - Use a scannable title: `[Subsystem] Action Description #Issue` (e.g., `[IAM] Add role-based access control #567`).
+   - Include context in the summary: what changed, why, and any issue references.
+   - Use `[WIP]` for in-progress PRs to avoid premature merging or choose GitHub draft PRs.
+
+2. **Commits**:
+   - Write clear messages: what changed and why (e.g., “Refactor S3 API handler to reduce latency so that requests process 20% faster”).
+   - Rebase to tidy commits before submitting (e.g., `git rebase -i main` to squash typos or reword messages), unless multiple contributors worked on the branch.
+   - Keep PRs focused—one feature or fix. Split large changes into multiple PRs.
+
+3. **Testing**:
+   - Include unit tests for new functionality or bug fixes.
+   - Ensure existing tests pass (`make test`).
+   - Document testing steps in the PR summary if manual testing was performed.
+
+4. **Before Submitting**:
+   - Run `make verify` to check formatting, linting, and tests.
+   - Reference related issues (e.g., “Closes #1234”).
+   - Notify team members via GitHub `@mentions` if urgent or complex.
+
+## Reviewing PRs
+
+Reviewers ensure MinIO’s commit history remains a clear, reliable record. Responsibilities include:
+
+1. **Commit Quality**:
+   - Verify each commit explains *why* the change was made (e.g., “So that…”).
+   - Request rebasing if commits are unclear, redundant, or lack context (e.g., “Please squash typo fixes into the parent commit”).
+
+2. **Code Quality**:
+   - Check adherence to MinIO’s Go standards (e.g., error handling, documentation).
+   - Ensure tests cover new code and pass CI.
+   - Flag bugs or critical issues for immediate fixes; suggest non-blocking improvements as follow-up issues.
+
+3. **Flow**:
+   - Review promptly to avoid blocking progress.
+   - Balance quality and speed—minor issues can be addressed later via issues, not PR blocks.
+   - If unable to complete the review, tag another reviewer (e.g., `@username please take over`).
+
+4. **Shared Responsibility**:
+   - All MinIO contributors are reviewers. The first commenter on a PR owns the review unless they delegate.
+   - Multiple reviewers are encouraged for complex PRs.
+
+5. **No Self-Edits**:
+   - Don’t modify the PR directly (e.g., fixing bugs). Request changes from the submitter or create a follow-up PR.
+   - If you edit, you’re a collaborator, not a reviewer, and cannot merge.
+
+6. **Testing**:
+   - Assume the submitter tested the code. If testing is unclear, ask for details (e.g., “How was this tested?”).
+   - Reject untested PRs unless testing is infeasible, then assist with test setup.
+
+## Tips for Success
+
+- **Small PRs**: Easier to review, faster to merge. Split large changes logically.
+- **Clear Commits**: Use `git rebase -i` to refine history before submitting.
+- **Engage Early**: Discuss complex changes in issues or Slack (https://slack.min.io) before coding.
+- **Be Responsive**: Address reviewer feedback promptly to keep PRs moving.
+- **Learn from Reviews**: Use feedback to improve future contributions.
+
+## Resources
+
+- [MinIO Coding Standards](https://github.com/minio/minio/blob/master/CONTRIBUTING.md)
+- [Effective Commit Messages](https://mislav.net/2014/02/hidden-documentation/)
+- [GitHub PR Tips](https://github.com/blog/1943-how-to-write-the-perfect-pull-request)
+
+By following these guidelines, we ensure MinIO’s codebase remains high-quality, maintainable, and a joy to contribute to. Happy coding!
diff --git a/README.fips.md b/README.fips.md