Source note: LemonLoader is independent. Project-specific facts below are limited to information published by the LemonLoader repository, releases, or wiki; general troubleshooting advice is identified by context.
Use GitHub as the archive
The reliable release archive is the project’s GitHub Releases page. It is preferable to a third-party “old versions” list because tags and notes come from the repository itself.
Do not inflate the archive
A version table should only contain releases that can be verified. If a release tag, date, or asset cannot be confirmed, omit it rather than creating a plausible-looking sequence.
How to compare versions
- Open the relevant release tag.
- Read whether changes affect core LemonLoader or only the installer.
- Review warnings that may alter installation or backup behavior.
- Use the asset attached to that exact tag.
Current anchor
At build time, the release page marks 0.6.5.1 as latest. Re-check GitHub before relying on that value in the future.
Version numbers need context
A release number alone does not explain what changed. Read whether the notes describe core LemonLoader changes, installer changes, dependency changes, or narrow bug fixes. The 0.6.5.1 page is a good example because it explicitly characterizes the release as installer-only.
When documenting an older version, link to its exact tag rather than copying a version table from another site. Tags preserve the associated notes and assets together, which makes later auditing much easier.
When an old version is appropriate
Use an older release only when you have a concrete compatibility or regression reason and can still verify its source. “Older is safer” and “newest always works” are both poor assumptions. Keep the target app version and loader version paired in your notes so you can reproduce a working combination.
Recommended next step
For a clean path through the project, use the verified download page, follow the installation guide, and keep the logging guide available for troubleshooting.