# Changelog

To install the unreleased django-slugify-processor version, see
{ref}`developmental-releases`.

[pip](https://pip.pypa.io/en/stable/):

```console
$ python -m pip install --upgrade --pre django-slugify-processor
```

[uv](https://docs.astral.sh/uv/):

```console
$ uv add django-slugify-processor --prerelease allow
```

## django-slugify-processor 1.12.x (unreleased)

<!-- KEEP THIS PLACEHOLDER - DO NOT REMOVE OR MODIFY THIS LINE -->
- _Add your latest changes from PRs here_
<!-- END PLACEHOLDER - ADD NEW CHANGELOG ENTRIES BELOW THIS LINE -->

## django-slugify-processor 1.11.0 (2026-08-08)

django-slugify-processor 1.11.0 moves the supported Django range forward. Django
4.2 and 5.1 reached end of life, so the package now requires Django 5.2 LTS and
adds support for Django 6.0 and 6.1. The release also rebuilds the documentation
site around a purpose-built landing page and a navigable project section, and
tightens the test matrix so every job verifies the Python and Django pair it
claims to run. Existing slug processor behavior is unchanged.

### Breaking changes

#### Django 5.2 is the minimum supported release (#426)

Minimum `django>=5.2` (was `>=4.2`). Django 4.2 LTS reached end of life on
2026-04-07 and Django 5.1 on 2025-12-03, so neither receives security patches.
Django 5.2 LTS is supported upstream until 2028-04-30.

Projects pinned below 5.2 need to move Django forward before taking this
release:

```console
$ uv add 'django>=5.2'
```

Nothing else changes for them. {func}`~django_slugify_processor.text.slugify`
and its template filter behave the same, `SLUGIFY_PROCESSORS` is untouched, and
the package's own Python floor stays at 3.10.

### What's new

#### Django 6.1 support (#426)

django-slugify-processor supports Django 6.1 and 6.0. Both are declared in the
package's trove classifiers and covered by the test matrix.
{func}`~django_slugify_processor.text.slugify` and
{func}`~django_slugify_processor.templatetags.slugify_processor.slugify` needed
no changes, so projects can upgrade without revisiting `SLUGIFY_PROCESSORS`.

Django 6.x requires Python 3.12 or newer. Installations on Python 3.10 and 3.11
continue to resolve Django 5.2 LTS; the package's own Python floor is unchanged.

#### Package version metadata is available at import time

{data}`django_slugify_processor.__version__` now re-exports the version from
`django_slugify_processor.__about__`. This gives
[Sphinx linkcode](https://www.sphinx-doc.org/en/master/usage/extensions/linkcode.html)
resolution and similar tooling a stable public place to read the installed
package version, which prevents generated source links from falling back to
malformed versionless URLs.

### Documentation

#### Library Skeleton documentation structure (#415)

The documentation site now opens with a purpose-built landing page instead of a
rendered README include. The first screen gives readers a direct path into
{ref}`quickstart`, {ref}`api`, and {ref}`project`, with short examples for
installing the package, registering `SLUGIFY_PROCESSORS`, and calling
{func}`~django_slugify_processor.text.slugify`.

Contributor material moved into a dedicated project section. Development setup,
code style, and release steps now live as navigable pages instead of one long
development note, so maintainers can point contributors at the exact workflow
they need.

#### Clearer slug processor setup guide (#421)

The quickstart now explains the processor pipeline directly: start from the
Django-compatible default, add one processor through `SLUGIFY_PROCESSORS`, then
use {func}`~django_slugify_processor.text.slugify` from Python or the matching
template filter from templates. Readers no longer need to leave the docs site
for the common setup path.

The landing and project pages also link first mentions of API objects,
Django utilities, and contributor tools to their reference pages. That makes the
documentation easier to skim while still giving deeper integrators a direct path
to the details they need.

#### Faster and steadier documentation browsing (#413, #416)

The docs gained the browsing polish first developed locally for this site:
self-hosted [IBM Plex](https://www.ibm.com/plex/) fonts, preload and fallback
metrics to prevent font-driven layout shifts, stable badge and logo sizing, and
SPA-like navigation that keeps the sidebar, theme state, and loaded assets in
place while moving between pages.

Those pieces are no longer carried as repo-local Sphinx extensions, templates,
CSS, and JavaScript. They now come from [gp-sphinx](https://gp-sphinx.git-pull.com),
so django-slugify-processor benefits from the shared git-pull documentation
stack without maintaining its own copy of the frontend machinery.

#### Shared API documentation design via gp-sphinx (#416, #417, #418, #419)

The API reference now uses the gp-sphinx autodoc stack for card-style function
signatures, cleaner Python cross-references, consistent badges, and IBM Plex
typography. The local Sphinx configuration shrank to the project-specific
settings around repository links, logos, intersphinx, and the
`sphinx_autodoc_api_style` extension.

The docs stack was refreshed through `gp-sphinx 0.0.1a17`, including the
[`gp-furo-theme`](https://pypi.org/project/gp-furo-theme/)
[Tailwind](https://tailwindcss.com/) v4 port of
[Furo](https://pradyunsg.me/furo/) and
[`sphinx-vite-builder`](https://pypi.org/project/sphinx-vite-builder/) for the
[Vite](https://vite.dev/) asset pipeline. Wheels now ship with built theme
assets, so installed docs dependencies render the site without each consumer
rebuilding the theme locally.

#### Copyable command examples (#414)

Documentation shell examples now use `console` code fences with `$` prompts and
split long commands with line continuations. The changelog's developmental
install commands, README examples, and contributor guidance follow the same
copy-friendly format.

#### Documentation publishing uses OIDC-backed AWS credentials (#410)

The docs deployment workflow now uses
[GitHub OIDC](https://docs.github.com/en/actions/concepts/security/openid-connect)
to assume the [AWS IAM](https://aws.amazon.com/iam/) role for the documentation
environment, syncs the built site with the [AWS CLI](https://aws.amazon.com/cli/),
and invalidates targeted [CloudFront](https://aws.amazon.com/cloudfront/) paths
after upload. That removes long-lived AWS access keys from the publishing path
while keeping the existing S3 and CDN deployment model.

#### Django documentation links follow the current release (#426)

Prose links and API cross-references into Django's documentation now resolve
against its current stable release instead of a pinned 4.2, so readers land on
the documentation for the Django they are running.

### Development

#### Task runner replaces the project Makefiles (#411)

Local development tasks now run through [just](https://just.systems/) at the
repository root and in `docs/`. The new recipes cover tests,
[Ruff](https://ruff.rs), [mypy](http://mypy-lang.org/), documentation builds,
documentation preview servers, and watch-mode workflows; the old root
`Makefile` and `docs/Makefile` were removed.

README, contributor docs, CI, and agent guidance now point at the same `just`
commands, so a maintainer can use one command vocabulary locally and in
automation.

#### Git-pull package pins bypass uv's freshness cooldown

The project now exempts git-pull-authored packages from uv's
`exclude-newer-package` cooldown. Fresh gp-sphinx and gp-libs releases can be
consumed immediately during coordinated workspace updates instead of blocking
every contributor's `uv sync` until a rolling freshness window expires.

#### Changelog authoring conventions are codified

`AGENTS.md` now records the release-note shape used by this changelog: lead
paragraphs, fixed section order, deliverable headings, PR references in
headings, and [MyST](https://myst-parser.readthedocs.io/) roles for documented
APIs. Future changelog edits have an explicit local standard instead of relying
on tribal knowledge.

#### CI actions updated to current majors

Workflow actions moved to their current major releases: `actions/checkout` v7,
`actions/cache` v6, `astral-sh/setup-uv` v9.0.0, `codecov/codecov-action` v7,
and `dorny/paths-filter` v4. Workflow behavior is unchanged, though setup-uv no
longer prunes the uv cache, so the first run after this repopulates it.

#### Lint floor moved to ruff 0.16 (#425)

Minimum `ruff>=0.16.0` (was unpinned). Contributors and CI now resolve the same
[Ruff](https://ruff.rs) instead of whichever version each machine happened to
pick up, so a local `ruff check` and the CI lint step report the same
diagnostics.

0.16.0 also formats Python code blocks inside Markdown, so `ruff format` covers
the docs tree and the root Markdown files alongside `src/` and `tests/`.

Linting runs on ruff's curated default rule set, with this project's own linters
layered on top through `extend-select`. Pylint, flake8-pyi, and flake8-bandit
checks now apply; the Sphinx config carries a scoped per-file ignore for the
`exec` it uses to read the package's metadata module.

#### The test matrix runs the versions it names (#426)

Each leg of the test matrix now runs the Python and Django pair it is labelled
with, and fails when it does not. Both axes were previously overridden before
the suite ran, so the matrix reported broader coverage than it actually had.

## django-slugify-processor 1.10.0 (2025-11-01)

django-slugify-processor 1.10.0 moves the supported runtime forward after
Python 3.9 reached end of life. The package now targets Python 3.10 and newer,
adds Python 3.14 to the supported and tested range, and refreshes the project
metadata so Django 5.2 appears in the public compatibility matrix. Existing
slug processor behavior is unchanged.

### Breaking changes

#### Python 3.9 support removed (#409)

Python 3.10 is now the minimum supported Python version. Projects still pinned
to Python 3.9 should stay on django-slugify-processor 1.9.x until they can
upgrade their runtime.

The test, lint, type-check, README, and dependency metadata all moved to the new
floor together so local development and CI agree on the same minimum.

### What's new

#### Python 3.14 is supported (#408)

The GitHub Actions test matrix now includes Python 3.14 alongside the existing
supported interpreters. The package classifiers and local tool-version files
were updated so installers and maintainers see the same compatibility story.

#### Developmental release installation docs

The changelog gained copyable install commands for pre-release testing via
`pip` and `uv`. See {ref}`developmental-releases` for the matching quickstart
guidance.

### Development

#### Deferred annotations throughout the package (#406)

The package now imports `from __future__ import annotations` where needed, and
Ruff enforces modern annotation forms. This reduces runtime annotation work and
keeps the codebase aligned with the Python versions supported by the 1.10.x
line.

## django-slugify-processor 1.9.0 (2024-12-20)

django-slugify-processor 1.9.0 is a maintenance release that raises the Python
floor to 3.9 and modernizes the codebase around that baseline. It does not add
new slugification behavior or bug fixes.

### Breaking changes

#### Python 3.8 support removed (#405)

Python 3.9 is now the minimum supported Python version. Python 3.8 reached end
of life on October 7, 2024, so future releases no longer test or advertise it.

### Development

#### Ruff modernization for the Python 3.9 floor (#404)

The codebase received an aggressive automated Ruff cleanup against the new
minimum runtime. This was a maintenance pass across formatting and lint fixes,
not a user-facing behavior change.

## django-slugify-processor 1.8.0 (2024-11-26)

django-slugify-processor 1.8.0 is the project-management and Django floor
release. It moves packaging from Poetry to uv and hatchling, drops Django 3.2
after its extended-support window, and keeps the public slugification API
focused on Django 4.2 and newer.

### Breaking changes

#### Django 3.2 support removed (#397)

Django 4.2 is now the minimum supported Django version. Projects still on
Django 3.2 should stay on django-slugify-processor 1.7.x until they can move to
a supported Django LTS line.

#### Project management moved from Poetry to uv (#402)

The repository now uses [uv](https://docs.astral.sh/uv/) for environment and
dependency management. Contributor setup, docs development, and CI dependency
installation all follow the uv workflow.

#### Build backend moved to hatchling (#402)

The package build backend changed from Poetry to
[hatchling](https://hatch.pypa.io/latest/). Source distributions and wheels now
build through the standard `[build-system]` backend declared in `pyproject.toml`.

### Development

#### Django 5.1 is part of the support matrix (#398)

CI and package classifiers now include Django 5.1. At the same time, unsupported
Django 4.0 and 4.1 metadata was removed from the active test grid.

## django-slugify-processor 1.7.0 (2024-08-17)

django-slugify-processor 1.7.0 is the final line that supports Django 3.2. The
release mainly prepares users for the upcoming Django 4.2+ floor while refreshing
linting and docs-link behavior.

### Upcoming deprecations

#### Final Django 3.2 branch

The 1.7.x series is the last branch intended for Django 3.2 users. The next
feature line, 1.8.x, removes Django 3.2 support after Django 3.2's extended
support ended on April 1, 2024.

### Documentation

#### Plain URLs are automatically linkified

Documentation pages now link URLs that were previously rendered as plain text,
making older release notes and references easier to follow.

### Development

#### Ruff linting tightened (#385, #386, #388)

The project adopted a stricter Ruff configuration and refreshed the codebase
with automated fixes from the newer Ruff release line. The added rule families
cover comma style, builtin shadowing, and exception-message hygiene; the changes
are development-quality improvements rather than runtime changes.

## django-slugify-processor 1.6.0 (2023-12-09)

django-slugify-processor 1.6.0 updates the Django compatibility window and
keeps the project small by removing unused settings code. It adds Django 5.0
coverage, removes old Django 4.0 and 4.1 test targets, and improves the
documentation surface with real docstrings.

### What's new

#### Django 5.0 compatibility (#382)

The package metadata and CI matrix now include Django 5.0. Because Django 5.0
sets its own Python floor, the test matrix was simplified around the latest
Python job for that line.

### Documentation

#### Public modules gained docstrings (#380)

Functions, classes, packages, and methods now have docstrings so generated API
documentation and doctest-oriented examples have real text to render.

### Development

#### Unused settings module removed (#381)

The old `django_slugify_processor.settings` module was deleted because the
package reads configuration from Django's normal settings object instead.

#### CI and linting refreshed (#380, #382)

CodeQL now uses GitHub's default setup, Ruff includes pydocstyle checks, and the
Django test grid reflects the currently supported versions.

## django-slugify-processor 1.5.0 (2023-11-18)

django-slugify-processor 1.5.0 is a maintenance release for contributor tooling.
The package runtime is unchanged, but formatting, dependency grouping, Python
classifier metadata, and GitHub Actions dependencies were brought up to date.

### Development

#### Formatting moved from Black to Ruff format (#379)

The project now uses `ruff format` for code formatting. This keeps the familiar
Black-style layout while removing a separate formatter dependency from the
development stack.

#### Poetry development dependencies were corrected

Development-only dependencies now use Poetry's dependency-group shape instead of
extras. That matches Poetry's own validation model and makes local installs less
surprising.

#### Python 3.12 and CI dependency updates

Package classifiers now include Python 3.12. GitHub Actions dependencies such as
`dorny/paths-filter` and `codecov/codecov-action` were refreshed to remove
workflow warnings and keep CI current.

## django-slugify-processor 1.4.0post0 (2023-10-07)

django-slugify-processor 1.4.0post0 is a documentation-only follow-up to the
1.4.0 release. It corrects README links so readers land on the current Django
documentation instead of stale version-specific pages.

### Documentation

#### README links point at current Django docs

The README was updated to point at the current Django documentation for the
slugify behavior that django-slugify-processor extends.

## django-slugify-processor 1.4.0 (2023-10-07)

django-slugify-processor 1.4.0 is a compatibility cleanup release. It drops
unsupported Python and Django versions, moves pytest configuration into
`pyproject.toml`, and makes the package strict-mypy compliant for maintainers.

### Breaking changes

#### Python 3.7 support removed (#374)

Python 3.8 and newer are now required. Projects still on Python 3.7 should stay
on an older django-slugify-processor release.

#### Django 2.2, 3.0, and 3.1 support removed

Django 3.2 and newer are now supported. The package no longer advertises or
tests the older Django lines removed in this release.

### What's new

#### Strict mypy compliance (#376)

The codebase now passes `mypy --strict`, giving maintainers a stronger type
checking baseline for future changes.

### Development

#### Pytest configuration lives in `pyproject.toml` (#375)

The repository moved pytest configuration out of standalone configuration files
and into the central project metadata file.

## django-slugify-processor 1.3.1 (2023-07-04)

django-slugify-processor 1.3.1 is a maintenance release focused on repository
tooling. It moves linting and formatting to Ruff, fixes CI typing behavior with
django-stubs, and simplifies packaging metadata.

### Development

#### Formatting, import sorting, and linting moved to Ruff (#372)

Ruff replaced the previous isort, flake8, and plugin stack for faster local
feedback. Additional Ruff rules were enabled so the project keeps a stricter
style baseline.

#### CI and type-checking infrastructure refreshed

CI moved to Python 3.11, Poetry moved to the 1.5 release line, and the
django-stubs settings-module issue in CI was fixed.

#### Packaging metadata simplified (#366)

Coverage configuration moved into `pyproject.toml`, `MANIFEST.in` was removed,
and an obsolete tmuxp setup hook was deleted.

## django-slugify-processor 1.3.0 (2022-09-11)

django-slugify-processor 1.3.0 moves the repository to the modern Python
library layout used by later releases. The package now lives under `src/`, docs
render through gp-libs Sphinx helpers, and the development stack adds stronger
linting.

### Documentation

#### Changelog and autodoc rendering use gp-libs helpers (#355, #360, #363)

The documentation site now uses gp-libs Sphinx helpers to link issue references
inside the changelog and to keep autodoc table-of-contents rendering stable.

### Development

#### Source package layout moved to `src/` (#364)

The Python package moved under a `src/` directory. This makes local test imports
match installed-package imports more closely and avoids accidentally relying on
repository-root import behavior.

#### Linting rules expanded (#361, #362)

The development stack added flake8-bugbear and flake8-comprehensions so CI can
catch common Python mistakes and simplification opportunities earlier.

## django-slugify-processor 1.2.0 (2022-08-16)

django-slugify-processor 1.2.0 establishes the testing and static-analysis
baseline that later releases build on. It adds doctest support, mypy validation,
cached dependency setup in CI, and a cleaner docs publishing condition.

### Development

#### Doctests and mypy validation (#359)

The test configuration now collects doctests and runs mypy with the Django stubs
plugin. That gives examples and type hints a place in the normal validation
flow.

#### CI dependency caching and docs publishing cleanup (#359)

GitHub Actions now use setup-python's dependency caching, and documentation
publishing is skipped unless the workflow conditions say docs should be
published.

#### Pre-commit configuration removed

The repository no longer carries a pre-commit configuration. Contributors can
run the documented commands directly instead of installing hooks that may not
match their local workflow.

## django-slugify-processor 1.1.1 (2022-03-08)

django-slugify-processor 1.1.1 is a small documentation and CI cleanup release.
It fixes README URLs and removes a tox integration that broke Poetry when run
inside an existing virtual environment.

### Documentation

#### README URLs corrected (#357)

Project links in the README were updated so readers reach the current source,
documentation, and package pages.

### Development

#### tox-poetry-installer removed from CI

The tox-poetry-installer integration was removed because it could break Poetry
commands when tox was already running inside a virtual environment.

## django-slugify-processor 1.1.0 (2022-03-08)

django-slugify-processor 1.1.0 updates the project identity after the repository
move to `tony/django-slugify-processor`. It also refreshes the docs theme and
keeps the codebase aligned with the Python 3.7 floor used at the time.

### Documentation

#### Documentation theme moved to Furo

The docs site adopted the Furo theme, giving the API and usage pages a cleaner
layout.

#### Repository URLs updated

Project metadata and documentation now point at
`https://github.com/tony/django-slugify-processor`.

### Development

#### pyupgrade run for Python 3.7

The codebase was modernized with pyupgrade for the Python 3.7 baseline.

## django-slugify-processor 1.0.0 (2022-01-08)

django-slugify-processor 1.0.0 is the first stable release after the early
series. It drops old Python support, adds Python 3.10 and Django 4.0 coverage,
and includes tests in source distributions so downstream packaging checks have
the same fixtures maintainers use.

### Breaking changes

#### Python 3.6 support removed (#350)

Python 3.7 and newer are required for the 1.x line.

### What's new

#### Python 3.10 and Django 4.0 compatibility (#350)

The package metadata and CI matrix were updated for Python 3.10 and Django 4.0,
keeping the slugify processor pipeline available on the then-current Django
release line.

#### Tests are included in source distributions (#350)

The `tests/` package is included in source distributions so downstream packagers
can run the project's own checks from the published artifact.

### Development

#### Poetry and tox workflow refreshed (#333, #350, #352)

Poetry moved to the 1.1 release line, tox was reworked around the project
dependencies, and a pre-commit configuration was added for local checks.

#### Runtime-version files updated

`.tool-versions` and `.python-version` were updated to list current patch
versions for the supported Python interpreters used by pyenv and asdf users.

## django-slugify-processor 0.11.0 (2021-06-16)

django-slugify-processor 0.11.0 moves the project documentation source to
Markdown. That makes the changelog and docs easier to maintain with the MyST
tooling adopted by later releases.

### Documentation

#### Documentation source moved to Markdown (#329)

The docs were converted from reStructuredText-oriented source files to Markdown
so project documentation could evolve with the rest of the git-pull docs stack.

## django-slugify-processor 0.10.0 (2021-06-16)

django-slugify-processor 0.10.0 removes legacy Python and Django compatibility
targets that were already outside normal support windows. It also cleans up
older UTF-8 compatibility shims.

### Breaking changes

#### Python 2.7, Python 3.5, and unsupported Django versions removed (#328)

The package now targets supported Python 3 and Django combinations. Projects
still on Python 2.7, Python 3.5, or unsupported Django releases should remain on
older django-slugify-processor versions.

### Development

#### Legacy UTF-8 compatibility code removed (#328)

Old UTF-8 helpers kept for Python 2 era compatibility were removed as part of
the runtime cleanup.

## django-slugify-processor 0.9.0 (2020-08-08)

django-slugify-processor 0.9.0 is the packaging and hosting modernization
release. The project moved from Pipenv to Poetry, Travis CI to GitHub Actions,
Read the Docs to git-pull-hosted documentation, and published package metadata
that better matched the supported Python and Django combinations.

### Documentation

#### Documentation moved to git-pull.com (#327)

The documentation URL moved to the git-pull.com hosting path, README badges and
links were refreshed, and the docs tree was renamed and reorganized for the new
publishing workflow.

### Development

#### Project management moved from Pipenv to Poetry (#327)

Pipenv files and setup.py-era packaging were replaced with Poetry and
`pyproject.toml`. The Makefile and tmuxp development helpers were updated around
the new environment manager.

#### CI moved from Travis to GitHub Actions (#327)

The old Travis configuration was removed and GitHub Actions workflows were added
for package checks and documentation publishing.

#### Compatibility metadata tightened (#327)

Package constraints and classifiers were updated so Python and Django version
support is expressed more accurately to installers and readers.

## django-slugify-processor 0.8.4 (2017-12-03)

django-slugify-processor 0.8.4 brings the early documentation online and cleans
up the generated API docs. It is a documentation-focused release for the first
public package line.

### Documentation

#### Hosted docs and API cleanup

The docs site came online, and the API documentation was cleaned up so users had
a stable place to learn the processor pipeline.

## django-slugify-processor 0.8.3 (2017-12-02)

django-slugify-processor 0.8.3 adds integration coverage around common Django
slug-field helpers. The test app and tests make sure the package works with the
model-field workflows users were likely to pair with custom slugification.

### What's new

#### Test app coverage for Django slug integrations

The release added a test app plus tests for django-extensions and
django-autoslug integration paths.

## django-slugify-processor 0.8.2 (2017-12-02)

django-slugify-processor 0.8.2 is a packaging-presentation follow-up to the
initial release. It adjusts the README and PyPI-facing content so the project
renders more clearly for installers.

### Documentation

#### README and PyPI rendering cleanup

The README was tweaked to improve how the package description appears on PyPI.

## django-slugify-processor 0.8.1 (2017-12-01)

django-slugify-processor 0.8.1 adds the template-filter path that lets Django
templates use the same slugification pipeline as Python code. This is the
release that makes overriding Django's built-in `slugify` filter practical in
template-heavy projects.

### What's new

#### Template filter override support

The package added a `slugify_processor` template tag module so templates can use
the custom slugify pipeline through a filter.

### Documentation

#### README usage expanded

The README gained instructions for overriding Django's built-in template filter
and using the package from templates.

## django-slugify-processor 0.8.0 (2017-11-26)

django-slugify-processor 0.8.0 is the initial public release. It introduces a
Django-focused slugification pipeline that lets projects run their own text
processors before falling back to Django's normal slug generation.

### What's new

#### Initial slugify processor pipeline

The first release established the core idea of the package: configure custom
processors for edge cases such as programming-language names or currency text,
then pass the result through Django's built-in slugify behavior.

<!---
# vim: set filetype=markdown:
-->
