}
    }

    def useCompilerPluginIfDefined() {
        // https://docs.scala-lang.org/scala3/guides/migration/plugin-kind-projector.html
        Assume.assumeTrue(
            VersionNumber.parse("2.12.14") <= versionNumber && versionNumber < VersionNumber.parse("2.13.0") ||

		return b, err
	}
	if err == nil {
		b.defaultTimestamps()
	}

	// If bucket metadata is missing look for legacy files,
	// since we only ever had b.Created as non-zero when
	// migration was complete in 2020-May release. So this
	// a check to avoid migrating for buckets that already
	// have this field set.
	if b.Created.IsZero() {
		configs, err := b.getAllLegacyConfigs(ctx, objectAPI)

			pvc:             getFakePersistentVolumeClaim("good-pvc", "vol-4", "2Gi", "2Gi", "good-pvc-vol-4"),
			pvcKey:          "default/good-pvc",
			expansionCalled: false,
		},
		{
			name:            "for csi plugin without migration path",
			pv:              getFakePersistentVolume("vol-5", "com.csi.ceph", "1Gi", "ceph-csi-pvc-vol-6"),
			pvc:             getFakePersistentVolumeClaim("ceph-csi-pvc", "vol-5", "1Gi", "2Gi", "ceph-csi-pvc-vol-6"),

No, an upgrade should not cause any downtime. However, on the first startup -
since MinIO will attempt to migrate any existing IAM data - the boot process may
take slightly longer, but may not be visibly noticeable. Once the migration has

platforms/documentation/docs/src/docs/userguide/api/kotlin_dsl.adoc                                 @gradle/bt-devrel-education @gradle/bt-kotlin-dsl-maintainers
platforms/documentation/docs/src/docs/userguide/migration/migrating_from_groovy_to_kotlin_dsl.adoc  @gradle/bt-devrel-education @gradle/bt-kotlin-dsl-maintainers

Two approaches to migrations stand out:

 * Migrating the existing syntax of your build to Kotlin, bit by bit, while retaining the structure — what we call a _mechanical migration_
 * Restructuring your build logic towards Gradle best practices and switching to Kotlin DSL as part of that effort

Both approaches are viable.
A mechanical migration will be enough for simple builds.

	// storedVersions lists all versions of CustomResources that were ever persisted. Tracking these
	// versions allows a migration path for stored versions in etcd. The field is mutable
	// so a migration controller can finish a migration to another version (ensuring
	// no old objects are left in storage), and then remove the rest of the
	// versions from this list.

        // It would be better to separate these into different scopes, but many things still assume that connection services are available in the global scope,
        // so keep them merged as a migration step
        // It would also be better to create the build process services only if they are needed, ie when the tooling API is used in embedded mode

	// storedVersions lists all versions of CustomResources that were ever persisted. Tracking these
	// versions allows a migration path for stored versions in etcd. The field is mutable
	// so a migration controller can finish a migration to another version (ensuring
	// no old objects are left in storage), and then remove the rest of the
	// versions from this list.

	// DEK entries, but that cache has an aggressive TTL to keep the size under control.
	// with DEK/seed reuse and no storage migration, the number of entries in this cache
	// would be approximated by unique key IDs used by the KMS plugin
	// combined with the number of server restarts.  If storage migration
	// is performed after key ID changes, and the number of restarts
	// is limited, this cache size may be as small as the number of API