* implementations.
     *
     * Changes in between these calls (as long as the file is open) are buffered by the server, so iteratively calling
     * this method should provide all changes (size of that buffer can be adjusted through
     * {@link jcifs.Configuration#getNotifyBufferSize()}).
     * If the server cannot fulfill the request because the changes did not fit the buffer
     * it will return an empty list of changes.

    }

    /**
     * Checks if directory change notifications are enabled for cache invalidation
     * @return true if change notifications are enabled
     */
    public boolean isNotificationEnabled() {
        return notificationEnabled;
    }

    /**
     * Enables or disables directory change notifications
     * @param notificationEnabled true to enable change notifications
     */

 */
package jcifs.internal;

import java.util.List;

import jcifs.FileNotifyInformation;

/**
 * Interface for SMB change notification response messages.
 * Handles responses from directory change notification requests, providing information
 * about file system changes such as file creation, deletion, or modification events.
 *
 * @author mbechler
 */

        retrievedPlugin.setVersion("3.11.0");

        // Verify the change persists when getting the plugin again
        Plugin pluginAfterModification = project.getPlugin("org.apache.maven.plugins:maven-compiler-plugin");
        assertEquals(
                "3.11.0",
                pluginAfterModification.getVersion(),
                "Version change should persist - this verifies the plugin is connected to the model");

     * called right before the actual version/artifactScope changes were done. However, a different set of conditionals
     * (and more information) is needed to be able to determine when and if the version and/or artifactScope changes.
     * See the two added methods, manageArtifactVersion and manageArtifactScope.
     */
    @Override

FastAPI also follows the convention that any "PATCH" version change is for bug fixes and non-breaking changes.

/// tip

The "PATCH" is the last number, for example, in `0.2.3`, the PATCH version is `3`.

///

So, you should be able to pin to a version like:

```txt
fastapi>=0.45.0,<0.46.0
```

Breaking changes and new features are added in "MINOR" versions.

            }
        }
    }
}

// We support multiple accepted public api changes JSON files, but "accepted-public-api-changes.json"
// is the "main" one that is also shown in HTML report
def apiChangesJsonDirectory = layout.projectDirectory.dir("src/changes/accepted-changes")

def compatibilityBaselineVersion = gradleModule.identity.releasedVersions.get().mostRecentRelease.version

Sebastián Ramírez <******@****.***> 1731896744 +0100

    },
    "tested": {
      "name": "type:tested",
      "colour": "#00ff00",
      "description": "tested"
    },
    "breaking_change": {
      "name": "type:breaking change",
      "colour": "#CF2E1F",
      "description": "breaking change"
    }
  },
  "issue": {
    "with_playground": {
      "requires": 1,
      "conditions": [
        {
          "type": "descriptionMatches",

# error: Your local changes to the following files would be overwritten by checkout:
#         integration-tests/gradle/gradle/wrapper/gradle-wrapper.jar
#         integration-tests/gradle/gradle/wrapper/gradle-wrapper.properties
#         integration-tests/gradle/gradlew
#         integration-tests/gradle/gradlew.bat
# Please commit your changes or stash them before you switch branches.