Merge remote-tracking branch 'upstream/main'

          [jsr:@fedify/h3]: https://jsr.io/@fedify/h3@${{ steps.versioning.outputs.version }}

          [npm:@fedify/h3]: https://www.npmjs.com/package/@fedify/h3/v/${{ steps.versioning.outputs.short_version }}

          [npm:@fedify/nestjs]: https://www.npmjs.com/package/@fedify/nestjs/v/${{ steps.versioning.outputs.short_version }}

          [npm:@fedify/next]: https://www.npmjs.com/package/@fedify/next/v/${{ steps.versioning.outputs.short_version }}

          [jsr:@fedify/postgres]: https://jsr.io/@fedify/postgres@${{ steps.versioning.outputs.version }}

          [npm:@fedify/postgres]: https://www.npmjs.com/package/@fedify/postgres/v/${{ steps.versioning.outputs.short_version }}

          [jsr:@fedify/redis]: https://jsr.io/@fedify/redis@${{ steps.versioning.outputs.version }}

### Branch Types

1. **main**: Contains unreleased development for the next major/minor version

2. **x.y-maintenance**: Maintenance branches for released major/minor versions

1. **next**: Contains unreleased development for the next major version

2. **main**: Contains unreleased development for the next minor version

3. **x.y-maintenance**: Maintenance branches for released major/minor versions

   (e.g., `1.5-maintenance`, `1.6-maintenance`)

### Development Workflow

- **New features**: Always target the `main` branch

- **Breaking changes**: Target the `next` branch

- **New features**: Target the `main` branch

- **Bug fixes**: Target the oldest applicable maintenance branch that contains

  the bug

3. Merge the fix into the next maintenance branch (e.g., `1.6-maintenance`)

4. Create a new patch release tag for that branch (e.g., `1.6.1`)

5. Continue merging forward through all subsequent maintenance branches

6. Finally merge into `main`

6. Merge into `main`

7. Finally merge into `next`

This ensures that all maintenance branches and the main development branch

This ensures that all maintenance branches and the development branches

include the fix.

3. Update documentation for API changes

4. Verify examples work with the change

5. Update CHANGES.md with details

6. Target the main branch

6. Target the main branch for non-breaking changes, or the next branch for breaking changes

Build and Distribution

To be released.

### @fedify/fedify

 -  Changed how `parseSoftware()` function handles non-Semantic Versioning

    number strings on `tryBestEffort` mode.  [[#353], [#365] by Hyeonseo Kim]]

### @fedify/cli

 -  Added `Next.js` option to `fedify init` command. This option allows users

    to initialize a new Fedify project with Next.js integration.

    [[#313] by Chanhaeng Lee]

 -  Changed how `fedify nodeinfo` command handles non-Semantic Versioning

    number strings on `-b`/`--best-effort` mode.  Now it uses the same logic as

    the `parseSoftware()` function in the *@fedify/fedify* package, which

    allows it to parse non-Semantic Versioning number strings more flexibly.

    [[#353], [#365] by Hyeonseo Kim]]

 -  Added `-T`/`--timeout` option to `fedify lookup` command. This option allows

    users to specify timeout in seconds for network requests to prevent

    hanging on slow or unresponsive servers.

    [[#258] by Hyunchae Kim]

### @fedify/next

 -  Created [Next.js] integration as the *@fedify/next* package.

[Next.js]: https://nextjs.org/

[#313]: https://github.com/fedify-dev/fedify/issues/313

[#353]: https://github.com/fedify-dev/fedify/issues/353

[#365]: https://github.com/fedify-dev/fedify/pull/365

Version 1.8.5

#### Branch types

 -  **main**: Contains unreleased development for the next major/minor version.

 -  **next**: Contains unreleased development for the next major version.

 -  **main**: Contains unreleased development for the next minor version.

 -  **x.y-maintenance**: Maintenance branches for released major/minor versions

    (e.g., *1.5-maintenance*, *1.6-maintenance*).

#### Target branches

 -  **New features**: Always target the *main* branch.

 -  **Breaking changes**: Target the *next* branch.

 -  **New features**: Target the *main* branch.

 -  **Bug fixes**: Target the oldest applicable maintenance branch that contains

    the bug.

 3. Merge the fix into the next maintenance branch (e.g., *1.6-maintenance*).

 4. Create a new patch release tag for that branch (e.g., `1.6.1`).

 5. Continue merging forward through all subsequent maintenance branches.

 6. Finally merge into *main*.

 6. Merge into *main*.

 7. Finally merge into *next*.

This ensures that all maintenance branches and the main development branch

This ensures that all maintenance branches and the development branches

include the fix.

### Bug fix

 -  The *CHANGES.md* entry.  The entry should include the issue number,

    the pull request number, and your name (unless you want to be anonymous).

Feature pull requests should target the *main* branch.

Feature pull requests should target the *main* branch for non-breaking changes,

or the *next* branch for breaking changes.

### Pull request builds

Backers

-------

Robin Riley, yamanoku, taye, Encyclia, okin, box464, Evan Prodromou, Rafael Goulart, malte, Andy Piper

Robin Riley, yamanoku, Encyclia, taye, okin, box464, Evan Prodromou, Rafael Goulart, malte, Andy Piper

One-time donations

------------------