Subscribers want to know the packages they depend on will be maintained into the future. We provide a set of tools to help you better plan the long-term maintenance of your project.
Continue to actively maintain your project
You must continue to be (one of) the maintainers of your package, as long as you're signed on as a lifter. This should mean you're looking at issues that are coming in, thinking about what should be done with the package over time, and generally keeping it on track—whatever "on track" means for your package.
Some packages should be quite low-activity (if they're mature and users want stability), but even these need someone keeping an eye on them in case of a security vulnerability or other surprise. We don't expect pointless activity; we just need you to be responsible for the package.
Our hope, of course, is that eventually income from Tidelift frees up the bulk of your time to make your package amazing—whatever that means to you and your project community.
We show subscribers release notes to help them understand a clear upgrade path at a glance. Release notes are rendered from Markdown or RST and you can input them manually, use our API, load them from a URL, or, if your package is on GitHub, load notes from GitHub Releases. By inputting release notes into the Tidelift application, we can save subscribers time and effort by showing all their dependency release notes in one place.
Manual input or via API
Enter your notes manually in the dashboard or via our API.
GitHub release notes
Choose this method to sync and auto-publish all release notes from GitHub. Here is the GitHub documentation on creating releases.
Release notes URL
Enter the URL to a raw Markdown/RST document and release notes will be read from there. Follow the keepachangelog.com format if using Markdown.
Due to caching, it can take up to 10 minutes for us to load notes from some hosting services, like GitHub.
If you enter in a non-raw GitHub URL, we'll change it to the raw URL for you.
Tidelift subscribers need your help to use the most appropriate version of your package, so we prompt you to indicate which versions are: active, receiving security fixes, or deprecated. In the future, we may require that active versions not rely on deprecated versions of other dependencies.
Please indicate which streams are safe for use until newer versions are available and which release streams are actively maintained. If you have an existing commitment to offer long-term support (LTS), let us know which streams(s) are supported and for how long. By default, new streams are considered safe for use until newer, as-safe or safer release streams exist.
Resolve issues affecting subscribers
We scan releases of your package to assess whether they will introduce issues for subscribers and notify you of any problems detected with your project (and its transitive dependencies). If any issues are detected, we'll guide you to find and fix the root cause and get the issues resolved quickly.
We'd like you to address flagged issues with your own dependencies, because subscribers will inherit them if you don't. (If an issue is bogus or not realistic to fix, it's legitimate to address it by ignoring it in .tidelift.yml though. Please email support if you don't understand an issue or think it's a bug.)
If a package you depend on has permanent problems, such as a lack of maintenance or a problematic license change, it probably makes sense to find an alternative to that package when possible. The problem dependency will be a problem for subscribers too, but they won't be able to fix it if your package is pulling it in indirectly.
Follow the Code of Conduct
You are required to follow our Code of Conduct in your interactions with subscribers, project contributors, Tidelift employees and other lifters.