- How do I install capell-app/demo-kit with Composer?
- Install it as a dev dependency from the Capell repository, then run the package's Artisan commands to publish configuration and seed the demo content. Because the package is on a beta channel, pin the exact tag (for example v1.1.0-beta.51) and commit your composer.lock rather than floating the constraint. Treat installation as a one-off scaffold step in a disposable or clearly guarded environment, not something you add to a production service provider stack.
- Which Laravel and PHP versions does capell-app/demo-kit support?
- The supported Laravel and PHP version matrix is not documented in the material available for this package, so you should treat compatibility as unverified rather than assumed-good. Before you schedule any work around it, run the package against your actual Laravel and PHP versions in a throwaway app and record the result. Also check the package's composer.json constraints on the repository as the most reliable source of truth. Once you have that matrix, keep it as your own internal reference for future Laravel upgrades.
- Is capell-app/demo-kit safe to use in production?
- No. Capell Demo Kit is intended for local development, staging, client previews, and onboarding, and its own documentation scopes it to those environments. It is a demonstration and scaffolding kit rather than a runtime library, and it ships on a beta channel with no changelog or backwards-compatibility statement. Keep it out of customer-facing delivery paths and isolate any evaluation in a separate repository or a clearly named branch with a CI guard.
- What demo content does Capell Demo Kit actually seed?
- It provides realistic sample pages and content structures along with configuration so a Capell application has something meaningful to render immediately. The goal is to let you explore the CMS core features without hand-authoring pages, blocks, or data records yourself. The exact set of pages and records depends on the demo data set you select, so inspect the seeders and published files after install to see what lands in your database.
- Can I customize the demo data sets and publish the configuration?
- Yes, the package is described as offering configurable demo data sets that you can match to your project. After publishing the config and migrations, edit or extend the seeders so the generated pages reflect your own content model and naming. Review the published files as part of your spike so you have a baseline fingerprint of config, migrations, and routes to compare against later versions.
- Why is capell-app/demo-kit still in beta at v1.1.0-beta.51?
- The package is currently published on a beta channel, and 51 betas on a single minor version signals active churn rather than a near-final release. There is no published stable release date and no explicit semver guarantee during the beta window. Treat beta as the intended channel until a non-beta release ships with a real changelog. If a stable release matters to your roadmap, do not build external commitments on this package yet.
- Is capell-app/demo-kit a scaffold or a long-term dependency?
- It reads as a scaffold and reference implementation for the Capell ecosystem, consumed once to spin up a working demo rather than a dependency consumed continuously at runtime. That framing matters: it helps a team answer questions about Capell cheaply, but it is not something you would wire into a product feature path. Decide explicitly which mode you are in before installing, because the easiest failure mode is an engineer quietly promoting a spike into a real service.
- Where is the changelog for releases like beta.50 and beta.51?
- There is no human-readable changelog for recent releases; the release notes contain only a compare link with no migration notes, backwards-compatibility statement, or security note. The only reliable way to recover what changed is to read the diff between tags directly on GitHub. Budget roughly one to two hours per version bump for that manual review while the package stays in beta.
- Should I require capell-app/demo-kit with a caret constraint like ^1.1@beta?
- No. A floating beta constraint means a routine composer update can silently pull a schema-breaking change that carries no changelog. Pin the exact tag, commit composer.lock, and treat every future bump as a reviewed commit with the diff read first. This is especially important when releases carry no release notes to tell you whether a change is cosmetic or breaking.
- How do I evaluate capell-app/demo-kit without risking my product codebase?
- Stand up an isolated evaluation repository, or a clearly named branch protected by a CI guard, pin the exact beta tag, and run the install in a disposable environment. Capture artisan about output, published config, migrations, and routes so you have a baseline fingerprint, then run the compatibility check against your target Laravel and PHP versions. Note that there is no evident commercial support or SLA, so GitHub issues are likely your only escalation path, and a security disclosure route is not documented.