revert: various changes

[ChipWolf]

I'll start by saying I'm sincerely grateful for @okafke's recent contributions, but I have to revert many of these changes.

These changes contained a new CI workflow that ran an extremely brittle Python script of which the output was used to fire off a commit that triggers the lifecycle CI workflow. Functionality was shoehorned into lifecycle to parse the new workflow's commit message to decide what to do.
Lifecycle is already quite complex, this change was generally poorly architected and needs to be thought out if we implement anything like this in future.

The script also blindly modifies README.md, gradle.properties files in new directories that are blindly copied, fabric.mod.json files (Fabric mod metadata), mods.toml files (Forge/NeoForge mod metadata), lifecycle.yml workflow file (the actual CI pipeline), and its own source code (the script file itself). The script depends on external APIs (Mojang, PrismLauncher) with zero error handling.

These are cardinal sins in software engineering. Scripts that modify themselves are unpredictable and basically impossible to debug.

[Copilot]

Pull Request Overview

This PR reverts AI-generated changes that added automated Minecraft version detection and PR creation functionality. The changes cleanly remove the automation infrastructure while preserving the core workflow functionality.

• Removes automated Minecraft version checking workflow and associated Python script
• Cleans up lifecycle workflow by removing PR comment parsing logic
• Reverts README example to use Minecraft version 1.21.4 instead of 1.21.5

Reviewed Changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
requirements.txt	Removed Python dependencies file (no longer needed without Python automation)
check-for-new-mc-versions.py	Removed Python script that automated Minecraft version detection
.github/workflows/new-mc-version.yml	Removed workflow that checked for new Minecraft versions on a schedule
README.md	Reverted example Minecraft version from 1.21.5 to 1.21.4
.gitignore	Removed .venv/ entry (no longer needed without Python development)
.github/workflows/lifecycle.yml	Removed PR comment parsing logic and simplified matrix filtering logic

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ChipWolf]

Raising #110 to at least eliminate the need to inject into the workflow YAML
We should probably focus efforts on not needing largely the same code in several versioned folders

Also #47 would largely mitigate the need for much of the automation
We could have a much simpler workflow that would update a machine-readable version manifest with a PR, again see Renovate.

[okafke]

Raising #110 to at least eliminate the need to inject into the workflow YAML

This is absolutely valid, that was an insanely bad idea. I will add a json file that the workflow reads and that the script modifies instead of the workflow itself. Also the script should not modify itself, but instead keep that information in a separate file too. I was pretty tunnel visioned on getting the projects to run again when I made this.

Reading the PR body was done to make the workflow build & run the newly added versions, because on a minor version update no code changes in the project directory are made and the workflow would thus not see the need to build & run anything in that version. That is also not the greatest idea, I'll think about something.

Also #47 would largely mitigate the need for much of the automation
We could have a much simpler workflow that would update a machine-readable version manifest with a PR, again see Renovate.

3arthqu4ke told me he abandoned the mc-runtime-test-mod projects as manifold is hard to work with and not a dream to maintain. I have not yet gotten around to take an in-depth look into it but I do not think it would magically solve all our problems. One question would be how we would detect which version changes in that code base belong to, so that we can only run the workflow for that version, while also ensuring that these changes really did not affect the other versions.

[ChipWolf]

Please also revert #111, then we can collaborate properly on these features in future PRs
#111 was also rushed to merge, I need time to review and comment on this change.

I accept the repo has been largely unmaintained, but rushing changes in without any kind of oversight is haphazard.

Let's start by reverting all of these changes, then we can build up piece by piece with architecture that makes sense. I don't want to spend time here highlighting the several hallmarks of AI generated code in those changes, nor do I have a problem with using AI to help with this type of work, the issue I have mainly lies in the script that was introduced and the subsequent changes to the lifecycle workflow to shoehorn it in. That change added needless complexity that could've been handled far more elegantly.

I invested a large amount of time getting these workflows working neatly initially, I don't appreciate them being gutted without time to review and make comments.

There's a branch protection here to make sure that PRs are reviewed by someone else with write access, can you not bypass that in future please?

[okafke]

Please also revert #111, then we can collaborate properly on these features in future PRs #111 was also rushed to merge, I need time to review and comment on this change.

I don't think either one of us has an overabundance of time to sink into this project. The workflow helps me reduce the time spent to support new mc versions to a minimum.
I am willing to throw it away once similar functionality is available and would like to at least wait for a new mc version to be released.

I invested a large amount of time getting these workflows working neatly initially, I don't appreciate them being gutted without time to review and make comments.

I apologise for bypassing the review process.
As of #111 the changes to your workflow are absolutely minimal: it now simply reads the build/run data from a file and has the (admittedly rather unelegant) check for the PR comment to ensure the new versions are actually tested in the PR opened by the check-new-mc-version workflow.
These changes effectively make up just about 20 lines of code and by maintaining a list of supported versions in each gradle.properties we could also throw away the PR comment check, thus making your workflow stay basically unchanged except for now reading the build/run data from a file.

I think just throwing away the new workflow is rather nuclear and would prefer not to do it.

There's a branch protection here to make sure that PRs are reviewed by someone else with write access, can you not bypass that in future please?

Noted!