* 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.

      - name: Check for changes in ci-health repository
        id: check-changes
        run: |
          cd ${GITHUB_WORKSPACE}
          if [ -n "$(git status --porcelain)" ]; then
            echo "changes=true" >> $GITHUB_OUTPUT
          else
            echo "changes=false" >> $GITHUB_OUTPUT
          fi
      - name: Create Pull Request
        if: steps.check-changes.outputs.changes == 'true'

<!--
Please open pull requests against one of the following branches:

- master — default target for all changes (new features + bug fixes).  
  If the change should also go to maven-4.0.x, request a backport in the PR.

- maven-3.10.x — target for 3.x changes (new features + bug fixes).  
  If the change should also go to maven-3.9.x, request a backport in the PR.
  maven-3.9.x should receive only serious bug fixes, as it is approaching EOL.

    changes to be made to PR to pass quality checks and send it back or on a
    rare occasion we may reject it.

**3. Review**

-   For a valid PR, reviewer (person familiar with the code/functionality)
    checks if the PR looks good or needs additional changes.
-   If all looks good, the reviewer will approve the PR.
-   If a change is needed, the contributor is requested to make the suggested

    - [Other notable changes](#other-notable-changes-14)
- [v1.3.0-alpha.3](#v130-alpha3)
  - [Downloads](#downloads-15)
  - [Changes since v1.3.0-alpha.2](#changes-since-v130-alpha2)
    - [Action Required](#action-required-4)
    - [Other notable changes](#other-notable-changes-15)
- [v1.3.0-alpha.2](#v130-alpha2)
  - [Downloads](#downloads-16)
  - [Changes since v1.3.0-alpha.1](#changes-since-v130-alpha1)

     * to quickly open the changes file.  By then we can also regex that path out of the description
     * in order to create a changes {@link File} for further use in this class.
     *
     * @param data the report data containing a description to parse
     * @return accepted api changes reported upon, as a file
     */

Making and Submitting Changes
--------------

We accept Pull Requests via GitHub. The [developer mailing list][dev-ml-list] is the
main channel of communication for contributors.  
There are some guidelines which will make applying PRs easier for us:
+ Create a topic branch from where you want to base your work (this is usually the master branch).
  Push your changes to a topic branch in your fork of the repository.

## 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.

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.

    }

    def "can clean existing API changes"() {
        given:
        jsonFile << existingAcceptedApiChanges()

        when:
        jsonFileManager.emptyAcceptedApiChanges(jsonFile)

        then:
        jsonFile.text == nonExistentAcceptedApiChanges()
    }

    def "can clean non-existing API changes"() {
        given:
        jsonFile << nonExistentAcceptedApiChanges()