Newznab Tmux Laravel Package

Product Decisions This Supports

• Build vs. buy for indexer/search infrastructure: newznab-tmux is a mature, Newznab-compatible indexer application. Adopting it gives you release/site/group management, search API compatibility, and a Horizon-backed job pipeline without building that domain logic in-house.
• API compatibility commitments: Because it implements the Newznab API surface for downstream readers (Sonarr/Radarr-style clients), it lets you promise a standard integration contract instead of a bespoke one. Roadmap decisions about client support can lean on that compatibility rather than custom work.
• Feature prioritization via release cadence signal: Release 4.2 is dominated by Dependabot bumps (Carbon, PHPUnit 12.4→12.5, Horizon 5.35, Scout 10.19.1, intervention/image, symfony/http-client) plus two substantive workstreams — a JavaScript performance/maintainability refactor and a migration to spatie/laravel-html for markup generation. This tells you the maintainers are investing in maintainability and front-end hygiene, not net-new product surface. Plan roadmap items assuming no major new capabilities arrive from upstream; budget internal effort if you need them.
• Operational defaults as a deployment decision: 4.2 changes the default database connection to MariaDB. For a PM this is a hosting/support-matrix decision (documented stack: MariaDB primary, MySQL-family compatibility path) and affects onboarding docs, Docker images, and support tiers.
• Reliability investment in edge cases: The getVideoIDFromSiteID fix handling a zero siteID is a small, unglamorous correctness fix. It signals that ID/site-mapping logic has real-world null/zero inputs — worth noting if you plan to expose site-scoped features or analytics.
• Use cases: private usenet indexer for a community or internal team, a search/release backend feeding media automation clients, and a base to fork for branded or niche indexing.

When to Consider This Package

Consider adopting when:

• You need a Newznab-compatible indexer and want to avoid writing release parsing, group management, and search API code yourself.
• Your team is Laravel/PHP-fluent and comfortable operating Horizon queues, Redis, and a MariaDB/MySQL instance.
• You accept upstream-led maintenance — the project ships frequently but largely via automated dependency updates; your value-add is configuration, not core algorithm work.
• You are fine with the default stack moving to MariaDB or are willing to pin/override the connection for existing MySQL deployments.
• You can absorb routine dependency churn (PHPUnit 12.x minor jumps, Rector/php-cs-fixer bumps) — these imply an actively maintained CI but also mean PHP/runtime version floors may drift upward.

Look elsewhere when:

• You need a managed SaaS indexer with an SLA — this is self-hosted operational surface area (queues, workers, DB, search index via Scout).
• You require stable, semantically versioned public APIs with deprecation windows; 4.x release notes are dependency-oriented and do not enumerate breaking changes, so you must read diffs (e.g. the spatie/laravel-html migration, the MariaDB default) before upgrading.
• Your stack is not Laravel or you cannot run Horizon/Redis, or your DB standard is Postgres-only.
• You need multi-tenant or compliance-grade features — nothing in this release indicates investment there.

Adoption gate before upgrading from 4.1: verify (1) the default DB connection change against your existing config/env, (2) any view/helper overrides that assumed the previous HTML generation path now that spatie/laravel-html is in play, and (3) front-end customizations against the JS refactor.

How to Pitch It (Stakeholders)

To executives: This is an actively maintained, self-hosted indexer built on our existing Laravel/PHP stack — it replaces a meaningful chunk of custom search-and-release infrastructure with a proven, Newznab-compatible implementation, so downstream media tools integrate against a standard API rather than bespoke code. Release 4.2 is a maintenance release: security- and stability-relevant dependency updates across the framework, queue, and test tooling, plus an internal front-end and templating cleanup. No new product capability, no deliberate breaking API changes, and low upgrade risk. The one decision it forces is infrastructural: the project's default database is now MariaDB, which we should standardize on (or explicitly override) so support and onboarding stay coherent.

To engineering: 4.2 is almost entirely Dependabot-driven — Carbon, PHPUnit (12.3.x→12.5.1), Horizon 5.35.2, Scout 10.19.1, symfony/http-client, intervention/image, php-cs-fixer, Rector, phpdotenv. Three changes need real review before merge: the default connection switched to MariaDB (check config/database.php, env templates, and any deployment manifests), the migration to spatie/laravel-html (audit Blade partials, helpers, and any custom HTML builders for behavioral differences and escaping), and the JavaScript refactor (re-verify any forked assets, build pipeline, and browser-facing behavior). One functional fix lands — getVideoIDFromSiteID now handles a zero siteID — worth a regression test if we call that path. Treat this as a routine upgrade requiring a DB-config and templating audit, not a feature release.