Mappings for "other" versions

[ThexXTURBOXx]

This is rather a question which may lead to me providing some mappings for versions 1.3 to 1.5.1, but let's see how that works out :)
Overall, I am interested in what the current workflow is regarding creating mappings.
I have seen that there are mappings for pretty much every version (didn't check that) up to 1.2.5.
However, there are also mappings for 1.5.2 for some reason.
I would be very interested in mappings for these versions between 1.2.5 and 1.5.2 for Block Helper since I would really like to migrate to RetroMCP, but this is sadly holding me back for now.
Are your mappings generated using Matcher or something else?
And if it is something else, how could I help creating mappings for these "other" versions?
I thought about parsing the MCP format myself and converting these original mappings from the MCPs to tiny mappings.
However, I am unsure if that is what you are interested in or if you want to create these mappings from the ground up (or - as already said - using Matcher or something else).

Hence, if you would like me to just "port" the MCP mappings to tiny, I will gladly do that and create a PR.
If you have some other procedure, I would also like to help, but could need some information on which software you are using for this or what the current workflow roughly looks like :)

[PhoenixVX]

For versions which have original MCP mappings, we first port them over to Tiny mappings, then we optionally fix up areas where they can be improved such as parameter names.

Then we merge the client & server mappings (even for versions before 1.3/12w18a). After that, we remap the original Exceptor files to named mappings as RMCP (specifically RDI) remaps and adds exceptions at once. Finally, we add patches if necessary and zip up all the files, then upload them to this GitHub repository with proper versioning JSONs.

Modification Station is talking about upping the limit from 1.2.5 to 1.5.2/1.6.4 as these versions are 10 years old and are basically legacy versions, which is why RMCP has added 1.5.2 specifically.

For versions that don't have original MCP mappings, we match from versions that do and do the same process.

Most of the software used is either FabricMC's or custom software we make to port / merge mappings, or a bit of both.

[ThexXTURBOXx]

Thank you very much for your detailed response! I have a few follow-up questions, though (sorry for that!)

we optionally fix up areas where they can be improved such as parameter names.

I can create "initial versions" for the mappings if you want me to, however, I do not have enough time to fix too many things or add too many things to them. If that is okay for you (i.e., if you are willing to accept my work and then add some things yourself), I will gladly create those. Is that okay?

Most of the software used is either FabricMC's or custom software

Is there source code available for the latter or are you interested in me open-sourcing something?

[PhoenixVX]

Updating this for future posterity.

Many of the tools used to convert the original SRG/MCP mappings over to the Tiny format were used once and never again and were not battle tested to be used against different versions than what they were developed for. SRG and the MCP mapping format has changed numerous times over the course of MCP.

The initial conversion is pretty easy as it usually goes obfuscated -> srg -> mcp. In earlier versions of MCP, RGS is used instead of SRG but the format can be read much the same way.

Afterwards, one can use FabricMC Enigma to work on the mappings further, which is a simple Java Swing program to map classes/methods/fields/parameters. If one is porting mappings from one version to another, FabricMC's Matcher program (created by sfPlayer1) can match constructs between 2 JARs and output mappings based on those differences.

After that, the mappings must be merged to be used in v1.0 and later versions of RMCP which only accept merged mappings. This can be done by using MappingUtil#mergeMappings in RMCP or the TaskMergeMappings in the test plugin (which can be ran directly within RMCP GUI and CLI when running in development). Even if the version only has 1 side, the mapping must be merged such that named -> a / b side where named is on the left and the right namespaces are the obfuscated name for each side.

After that, exception files must be created which are in the format of net/some/package/SomeClass/SomeMethod Signature full/path/to/Exception which will add Exception to SomeClass/SomeMethod. For any decompilation issues that are not related to exceptions, patch files must be used which can be created by running the createpatch task which will output a single file patch for all the differences between the decompiled and current source code. Earlier versions of RMCP use folder patches which cannot be read by RMCP anymore.

You can view the wiki for more information on how exactly this is done.