Release 2.2.0

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -5,33 +5,35 @@ All notable changes to this project are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased]
+## [2.2.0] - 2026-09-19
 
 ### Added
 
 - The admin dashboard shows the installed SealShare version, with links to its release notes, the SealShare website and noNameWEB.
 
-### Fixed
-
-- Docker installs updated from 2.0 answered every upload with "409 Conflict". The example `docker-compose.yml` mounted the SQLite volume over all of `/app/database`, which hid the image's new migration, so it never ran. The container now adds the migrations the volume is missing before migrating, so existing compose files keep working.
-- A share with several files and a download limit was deleted as soon as one file was downloaded: every single file counted as a whole download. Now one recipient's visit counts once, and they have 1 hour to download all the files and the ZIP. Two recipients who start at the same moment can no longer both get the last download.
-- The scheduler container no longer shows as "unhealthy": it inherited the image's healthcheck, which asks the web server that only the app container runs. To fix an existing install, add `healthcheck: { disable: true }` to the scheduler service in your `docker-compose.yml`.
-- The "30 Days" expiration lasted a calendar month; it now lasts 30 days.
-- Admin settings only save a default expiration that is one of the offered options.
-
 ### Changed
 
-- `docker-compose.example.yml` mounts `sealshare_database` at `/app/database/sqlite` and sets `DB_DATABASE` to the file in it. To switch an existing install, mount the same volume there and set `DB_DATABASE: /app/database/sqlite/database.sqlite` in both services; the database is kept.
-- A share that reached its download limit is closed at once, but deleted by the hourly cleanup 24 hours after its last download instead of immediately, so downloads still running can finish. Until then its files still count towards the storage quota.
-- The download page of a share with a download limit says how many downloads are left, or how long the recipient can still download. The admin dashboard shows downloads as "2 of 3 downloads", marks shares at their limit as "Download limit reached" and no longer counts them as active.
+- `docker-compose.example.yml` mounts `sealshare_database` at `/app/database/sqlite` instead of `/app/database`, and sets `DB_DATABASE: /app/database/sqlite/database.sqlite`. Existing compose files keep working. To switch, mount the same volume at the new path and set `DB_DATABASE` in both services; the database is kept.
+- A share that reaches its download limit is closed at once, but deleted by the hourly cleanup 24 hours after its last download instead of immediately, so downloads still running can finish. Until then its files count towards the storage quota.
+- The download page of a share with a download limit says how many downloads are left, or how long the recipient can still download.
+- The admin dashboard shows downloads as "2 of 3 downloads" and marks shares at their limit as "Download limit reached". These no longer count as active shares.
 - The sort dropdown on the admin dashboard spans the full width of the shares card.
-- Development: `docker-compose.dev.yml` now extends `docker-compose.yml`, so the dev stack runs the scheduler and the production image's PHP extensions, and takes its settings from `.env` (which selects the file through `COMPOSE_FILE`). A Vite dev server with hot reload runs beside the app. No ports are published unless `docker-compose.ports.yml` is added; with OrbStack the app is at `https://app.sealshare.orb.local`. `docker/dev.Dockerfile` became the `dev` stage of the `Dockerfile`.
-- The Docker image's PHP limits (`PHP_UPLOAD_MAX_FILESIZE`, `PHP_POST_MAX_SIZE`, `PHP_MAX_EXECUTION_TIME`, `PHP_MAX_INPUT_TIME`, `PHP_MEMORY_LIMIT`) are read by PHP itself from the environment; the entrypoint no longer writes an ini file on start. The variables and their defaults are unchanged.
+- PHP reads the Docker image's limits (`PHP_UPLOAD_MAX_FILESIZE`, `PHP_POST_MAX_SIZE`, `PHP_MAX_EXECUTION_TIME`, `PHP_MAX_INPUT_TIME`, `PHP_MEMORY_LIMIT`) from the environment itself; the entrypoint no longer writes an ini file on start. The variables and their defaults are unchanged.
+- Updated to Livewire Material 2.2.0.
+- Development: `docker-compose.dev.yml` extends `docker-compose.yml`, so the dev stack runs the scheduler and the production image's PHP extensions, plus a Vite dev server with hot reload. It takes its settings from `.env`, and publishes ports only with `docker-compose.ports.yml`. `docker/dev.Dockerfile` became the `dev` stage of the `Dockerfile`.
+
+### Fixed
+
+- Docker installs set up before 2.1.0 answered every upload with "409 Conflict" after the update. The example `docker-compose.yml` mounted the SQLite volume over all of `/app/database`, which hid the image's new migrations, so they never ran. The container now adds the migrations the volume is missing before migrating.
+- A share with several files and a download limit was deleted as soon as one file was downloaded, because every file counted as a whole download. Now one recipient's visit counts once, and they have 1 hour to download all the files and the ZIP. Two recipients who start at the same moment can no longer both get the last download.
+- The scheduler container no longer shows as "unhealthy". It inherited the image's healthcheck, which asks the web server that only the app container runs. For an existing install, add `healthcheck: { disable: true }` to the scheduler service in your `docker-compose.yml`.
+- The "30 Days" expiration lasted a calendar month; it now lasts 30 days.
+- Admin settings only save a default expiration that is one of the offered options.
 
 ### Removed
 
 - Email verification (`/email/verify`), which was never enforced: SealShare has a single admin account and no registration.
-- The `composer dev` script: development runs in Docker (`docker-compose.dev.yml`).
+- The `composer dev` script and the packages only it used (`concurrently`, `laravel/pail`, `laravel/sail`, `autoprefixer`), with the `shell-quote` override that `concurrently` needed. Development runs in Docker (`docker-compose.dev.yml`).
 
 ## [2.1.0] - 2026-09-16
 
@@ -166,6 +168,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Dark themed UI built with Livewire, Alpine.js, Tailwind CSS and DaisyUI.
 - Docker images published to `ghcr.io/surtic86/sealshare`, served by FrankenPHP via Laravel Octane.
 
+[2.2.0]: https://gitea.nonameweb.ch/noNameWEB/SealShare/compare/v2.1.0...v2.2.0
 [2.1.0]: https://gitea.nonameweb.ch/noNameWEB/SealShare/compare/v2.0.1...v2.1.0
 [2.0.1]: https://gitea.nonameweb.ch/noNameWEB/SealShare/compare/v2.0.0...v2.0.1
 [2.0.0]: https://gitea.nonameweb.ch/noNameWEB/SealShare/releases/tag/v2.0.0

Dockerfile

@@ -114,7 +114,7 @@ RUN rm -rf node_modules tests .gitea docker/dev-entrypoint.sh .env .env.example
     storage/logs database/sqlite \
     && chmod -R 777 storage database bootstrap/cache
 
-# A docker-compose.yml from before 2.1.1 mounts the SQLite volume over all of database/, which hides
+# A docker-compose.yml from before 2.2.0 mounts the SQLite volume over all of database/, which hides
 # the migrations of every later image; the entrypoint adds the ones the volume is missing from here.
 RUN cp -R database/migrations docker/migrations
 

README.md

@@ -123,7 +123,7 @@ Migrations run automatically on startup. Open your configured domain — the Set
 | `caddy_data` | `/data` | TLS certificates |
 | `caddy_config` | `/config` | Caddy configuration |
 
-A `docker-compose.yml` from before 2.1.1 mounts `sealshare_database` at `/app/database`, which also hides the image's migrations; the container adds the ones the volume is missing on startup, so it keeps working. To move to the layout above, mount the same volume at `/app/database/sqlite` and set `DB_DATABASE: /app/database/sqlite/database.sqlite` in both services — the existing database is at that path then, and nothing is lost.
+A `docker-compose.yml` from before 2.2.0 mounts `sealshare_database` at `/app/database`, which also hides the image's migrations; the container adds the ones the volume is missing on startup, so it keeps working. To move to the layout above, mount the same volume at `/app/database/sqlite` and set `DB_DATABASE: /app/database/sqlite/database.sqlite` in both services — the existing database is at that path then, and nothing is lost.
 
 **Large files:**
 

config/app.php

@@ -25,6 +25,6 @@ return [
     |
     */
 
-    'version' => '2.1.0',
+    'version' => '2.2.0',
 
 ];