Maintenance life cycle
Keeping themes and extensions alive: upgrades, compatibility, security fixes and retirement.
38 pages
- Publishing a security release Release a security fix for a theme - fix, version, tag and release first, then describe the problem plainly with affected versions and the action users must take, and tell the channels where your users are.
- Keeping dependencies up to date Keep the libraries, fonts, icon sets and extensions a theme depends on current - an inventory, where updates are announced, testing an update, and checking licenses again.
- A deprecation policy Decide and publish how your theme retires settings, templates, view modes and operators - announce, keep working, warn, remove in a later step - so users have time to adapt.
- Deprecating a setting or a template Step by step - rename a theme setting while still reading the old name, replace a template while keeping an include of the old one, and remove both later - with the changelog entries for each step.
- Breaking changes and the next major version When a theme change forces users to act - removed templates or settings, a raised minimum version, a redesign - group it, move a higher version position deliberately, write an upgrade guide, and keep the previous line…
- End of life End maintenance of a theme responsibly - decide, look for a successor or new maintainer first, give notice, publish a last release, keep it installable, and archive - so users are never stranded without warning.
- Announcing end of life What an end-of-life announcement for a theme says - the date, what stops, what stays available, the successor or ways forward, and how to reach paying customers - with a text to adapt.
- Archiving a repository Archive a theme's GitHub repository so it stays readable and installable but takes no new changes, and mark the Packagist package as abandoned with a successor - without deleting anything.
- Handing a theme over to a new maintainer Pass a theme to a new maintainer so users notice nothing but continuity - choosing someone, a handover period, documentation, access, the repository and package, and announcing it.
- Transferring the repository and the Packagist package Move a theme's GitHub repository and Packagist package to a new owner without breaking installs - GitHub's transfer and redirect, the package name question, Packagist maintainers and the update hook.
- Adopting an abandoned theme Take over a theme whose author stopped maintaining it - ask first, then continue in the original repository if you are given access, or fork it under a new name; and how old extensions from the community archive can be…
- Forking a theme When to fork a theme and when to contribute instead, how to fork with history so you can still exchange changes, what the GPL asks of a fork, and how to tell users what your fork is.
- Rebranding a fork, fairly Give a forked theme its own identity without erasing its origin - a new name, package and design name, kept notices and license, a visible "based on" credit, and no implied endorsement - with what to change in which…
- Credits and attribution Credit everyone whose work is in a theme - original authors of ported or forked designs, contributors, reporters, third-party assets - in copyright lines, changelogs and README, with real examples from the 7x themes.
- Contributing back upstream Send fixes and improvements back to the themes, extensions and the Exponential project you build on - what to contribute, how to prepare a change, and why it pays off in less maintenance for you and shared growth for…
- Pull requests to someone else's theme Prepare a pull request that a maintainer can merge quickly - small and focused, explained, tested, with screenshots for visual changes and no unrelated or private content - and how to respond to review.
- Keeping a fork in sync Bring the original theme's fixes into your fork regularly - an upstream remote, fetch and merge, resolving conflicts in templates, and keeping your own changes small so merges stay easy.
- A maintenance calendar A rhythm for theme maintenance - weekly watching, per-release testing and audits, quarterly dependency and license reviews, a yearly review of support policy and compatibility - as a calendar to adapt.
Documentation license
This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.
Exponential Copyright © 1998-2026 Exponential Foundation and 7x