*
 * When merging `releaseX` branch into `master`, we should only use the release note from the `master` branch,
 * but sometimes changes on release notes.md was brought to master and merged unnoticed,
 * e.g https://github.com/gradle/gradle/pull/25825
 *
 * This script is to check if there is any merge commit that brings changes from release branch to master.
 * Usage: groovy CheckBadMerge.groovy <commit1> <commit2> ...

) {
    init {
        id("Promotion_SnapshotFromQuickFeedbackStepUpload")
        name = "Nightly Snapshot (from QuickFeedback) - Upload"
        description = "Builds and uploads the latest successful changes on '${branch.branchName}' from Quick Feedback as a new distribution"

        steps {
            buildStep(
                ******@****.***arameters,

  - [Changelog since v1.25.13](#changelog-since-v12513)
  - [Changes by Kind](#changes-by-kind-1)
    - [API Change](#api-change)
    - [Feature](#feature-1)
    - [Bug or Regression](#bug-or-regression-1)
    - [Other (Cleanup or Flake)](#other-cleanup-or-flake-1)
  - [Dependencies](#dependencies-2)
    - [Added](#added-2)
    - [Changed](#changed-2)
    - [Removed](#removed-2)
- [v1.25.13](#v12513)

plugins {
    id("gradlebuild.build-logic.kotlin-dsl-gradle-plugin")
    id("gradlebuild.build-logic.groovy-dsl-gradle-plugin")
}

description = "Provides a plugin for configuring japicmp-gradle-plugin to detect binary incompatible changes"

dependencies {
    api("me.champeau.gradle:japicmp-gradle-plugin")

    implementation("gradlebuild:basics")
    implementation("gradlebuild:module-identity")

    implementation("com.google.code.gson:gson")

#### Internal API changes

The `okhttp3.internal` package is not a published API and we change it frequently without warning.
Depending on code in this package is bad and will cause you problems with any upgrade! But the 4.x
will be particularly painful to naughty developers that import from this package! We changed a lot
to take advantage of sweet Kotlin features.

#### Credentials.basic()

## Creating a hotfix branch

Customers in MinIO are allowed LTS on any release they choose to standardize. Production setups seldom change and require maintenance. Hotfix branches are such maintenance branches that allow customers to operate a production cluster without drastic changes to their deployment.

## Backporting a fix

Developer is advised to clone the MinIO source and checkout the MinIO release tag customer is currently on.

   * Registers a {@link Listener} to be {@linkplain Executor#execute executed} on the given
   * executor. The listener will have the corresponding transition method called whenever the
   * service changes state. The listener will not have previous state changes replayed, so it is
   * suggested that listeners are added before the service starts.
   *
   * <p>{@code addListener} guarantees execution ordering across calls to a given listener but not

    - [Other notable changes](#other-notable-changes)
- [v1.15.7](#v1157)
  - [Downloads for v1.15.7](#downloads-for-v1157)
    - [Client Binaries](#client-binaries-5)
    - [Server Binaries](#server-binaries-5)
    - [Node Binaries](#node-binaries-5)
  - [Changelog since v1.15.6](#changelog-since-v1156)
    - [Other notable changes](#other-notable-changes-1)
- [v1.15.6](#v1156)

  - [Changelog since v1.24.13](#changelog-since-v12413)
  - [Changes by Kind](#changes-by-kind-3)
    - [API Change](#api-change)
    - [Feature](#feature-3)
    - [Bug or Regression](#bug-or-regression-3)
    - [Other (Cleanup or Flake)](#other-cleanup-or-flake)
  - [Dependencies](#dependencies-3)
    - [Added](#added-3)
    - [Changed](#changed-3)
    - [Removed](#removed-3)
- [v1.24.13](#v12413)

- On Operator based MinIO deployments, you need to modify the `tenant.yaml` specification and modify the `pools:` section from two entries to a single entry. After making relevant changes, proceed to execute `kubectl apply -f tenant.yaml`.