General Questions¶

This page answers high-level questions about the project, its scope, and its lifecycle.

What Is next.dj and Is It a Django Replacement ¶

next.dj is a framework built on Django, not a replacement for it. It adds file-based routing, a layout system, reusable components, and form dispatch on top of a regular Django project. See Overview, especially What next.dj Does Not Replace, for what stays stock Django versus what the framework adds.

Which Django and Python Versions Are Supported ¶

The Installation Requirements list names the tested Python and Django combinations.

Is next.dj Production Ready ¶

next.dj is used in production. Run manage.py check to confirm a deployment matches framework expectations, and pin a supported Python and Django release (see Installation). See Which Symbols Are Safe to Depend On below for guidance on the public API surface.

How Do I Follow the Project ¶

Watch the repository on GitHub. Releases ship through PyPI under the distribution name next.dj, imported as next (see Installation). Discussions and feature requests live on GitHub Discussions.

What About Plugins ¶

The project does not ship a plugin registry. The five extension mechanisms in Extending cover the common cases. Distribute your customisations as ordinary Python packages.

What About a CLI ¶

The framework does not add a new CLI. Django’s manage.py plus the framework system checks cover the operational surface.

Which Symbols Are Safe to Depend On ¶

Two rules define the public surface. First, anything exported from a top-level next.* package is safe to import. Second, symbols whose names start with a single underscore are internal and may change without notice, even when they appear in a module __all__. The underscore rule is binding and overrides any incidental re-export. See Forms Reference for a concrete example of how the API tiers apply to next.forms.