LLM Instructions: Upgrading Projects

This post acts as explicit instructions and rules for LLMs tasked with upgrading software projects. When applying an upgrade, you must follow these rules meticulously to ensure the project remains stable and up-to-date.

Upgrade Rules

When upgrading a repository, always target the latest versions of the following technologies:

1. Flutter & Dart: Ensure the project uses the latest stable releases.
2. GitHub Actions: Upgrade all actions to their latest major versions.
3. Go (Golang): Update to the latest stable Go release.
4. Dependencies: Upgrade all dependencies and dev dependencies where necessary.
5. Qt, KDE, and C++ Dependencies: Assume the latest versions available.
6. Linters: Ensure the linter is on the latest language-compatible version. Try to stick to safe defaults rather than relying heavily on custom configuration. Use configuration sparingly. Never bypass a lint warning or error without explicit user instruction. You are here to complete the task properly.

Important Checks During Upgrades

1. Verify External Sources: Always check external sources for the actual latest version (e.g., checking github.com/actions/checkout for the checkout action). LLM memory is often outdated or wrong and frequently overwrites defaults with older versions.
2. Local Environment Upgrades: Ensure that the local LLM environment version is also upgraded to match the target versions. This is crucial for local testing. If it cannot be done locally for whatever reason, utilize the CI system for testing.
3. Enforce Minimum Requirements: Minimum language requirements must be updated in the project’s configuration files (e.g., updating the go directive in go.mod, or the Flutter SDK version range in pubspec.yaml) to enforce the upgrade.
4. GitHub Actions Constraints: Check GitHub actions, all constants, and versions referred to. Ensure that, if possible, CI steps are bound to the versions specified in the code. For example, use go-version-file: go.mod instead of hardcoding a Go version in a GitHub Action, unless a hardcoded version is required for another specific reason (like regression testing, forward compatibility testing, matrix testing, etc.).

Upgrade Process and Testing

• Blindly Upgrade and Test: Dependencies are to be upgraded and tested for each version. Follow any upgrade roadmaps if provided by the dependency authors. Do not qualify with the user or wait for approval; assume these instructions to be true and proceed. Mistakes or nuances can be picked up during the PR review process.
• Use Docker: You can use Docker to pull the latest versions of tools and dependencies for isolated testing.
• Compatibility and Downgrading: Ensure that all dependencies and versions are compatible with one another. We might need to downgrade certain dependencies for version compatibility. If downgrading is necessary, pick the path of least resistance and present the options to the user before pushing. The state of the application before the upgrade is relevant; it should be better off afterwards.
• Increase Test Coverage: Increase testing for assurances that things still work as they used to. Tests can be written first and should focus heavily on known hotspots affected by the upgrade. Do your research to figure out exactly what to change and update.

Current Versions Reference Table

As of writing, the current latest versions of commonly used technologies based on common repositories are provided in the table below. When upgrading, check the provided locations to fetch the actual latest versions.

Core Languages & Frameworks

GitHub Actions

Common Go Dependencies

Common Dart/Flutter Dependencies

Other Dependencies