* IDE Analysis API.
 *
 * [KotlinMessageBusProvider] exists so that this default may change in the future without breaking the API. Hence, it should not be assumed
 * that the message bus provided by [KotlinMessageBusProvider] will always be equal to the project's message bus.
 */

        - label: "Has this idea, or one like it, been proposed before?"
        - label: "Does this affect error handling?"
        - label: "Is this about generics?"
        - label: "Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit"

  - type: textarea
    id: related-proposals
    attributes:
      label: Has this idea, or one like it, been proposed before?

    Signature(Buildable source, Callable<File> toSign, Callable<String> classifier, Callable<String> name, SignatureSpec signatureSpec, Object... tasks) {
        // TODO: find a way to inject a proper task dependency factory without breaking the public API
        super(DefaultTaskDependencyFactory.withNoAssociatedProject(), tasks);
        init(toSign, classifier, name, signatureSpec);
        this.source = source;
    }

    /**

import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

/**
 * Documents that the type or method is not referenced by the build scan plugin,
 * and therefore can be changed or removed without breaking it.
 *
 * @since 5.1
 */
@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface NotUsedByScanPlugin {

    /**

package org.gradle.api.plugins.jvm.internal;

import org.gradle.api.attributes.HasConfigurableAttributes;

/**
 * This type is deprecated and will be removed in a future version of Gradle - it exists only to
 * avoid breaking existing plugins.
 *
 * New code should use {@link JvmPluginServices} instead.
 *
 * @see <a href="https://github.com/gradle/gradle/issues/25542">Removal of JvmEcosystemUtilities Issue</a>
 */

=== Potential breaking changes

 * There have been several potentially breaking changes in Kotlin DSL — see the _Breaking changes_ section of https://github.com/gradle/kotlin-dsl/releases/tag/v1.0-RC3[that project's release notes].

/**
 * Workaround for <a href="https://github.com/melix/japicmp-gradle-plugin/issues/56">japicmp issue w.r.t. superclass breakage</a>.
 *
 * <p>
 * Reports simple superclass changes (e.g. the removal of a superclass) as a breaking change, as it affects what methods can be
 * called with the given type, even if the methods and fields inherited don't change.
 * </p>
 */
class BinaryBreakingSuperclassChangeRule extends AbstractSuperClassChangesRule {

This is in contrast to the **development** stages, where you are constantly changing the code, breaking it and fixing it, stopping and restarting the development server, etc.

## Deployment Strategies

There are several ways to do it depending on your specific use case and the tools that you use.

go1.txt (and similarly named files) are frozen once a version has been
shipped. Each file adds new lines but does not remove any.

except.txt lists features that may disappear without breaking true
compatibility.

Starting with go1.19.txt, each API feature line must end in "#nnnnn"
giving the GitHub issue number of the proposal issue that accepted
the new API. This helps with our end-of-cycle audit of new APIs.

            }
            if (infixChanged) {
                changes.add(modifierChangeDetail("infix", newIsInfix))
            }
            return acceptOrReject(member, changes, Violation.error(member, "Breaking Kotlin modifier change"))
        }

        return null
    }

    private static String modifierChangeDetail(String modifier, boolean added) {
        return "$modifier modifier was ${added ? "added" : "removed"}"