tokay
Hello and welcome to the forum, tokay 🙂
It would be simple enough, to offer different export options, like just exporting the current app (without dependencies) as formatted JSON - with or without version number. I´ll add it to our wish list for future releases. We would however need to be careful, not to make these options too prominent; from my experience, most do not know what´s in a *.rei file. They export their changes and are happy not to know, that this is a zip file, containing the app as well as dependencies. The more options we show, the more we expose complexity - but an "expert options" toggle would probably be enough to signal that this is not for most people. We haven´t touched the export UI in years, might as well 🙂
The first prototype of r3 (back in 2019) had a change tracking feature that stored each change in a big list - which was also used to import r3 apps by implementing all changes, step-by-step, in a target r3 instance. It was however an inefficient system and quite unwieldly to deal with new features and changes in how the different components of r3 interacted.
But coming back to your suggestions. We are developing r3 apps for ourselves, the public as well as clients for some years now and I find comparing versions on a JSON-to-JSON level not particularly useful. Even if the files were formatted and/or r3 would resolve UUIDs to internal names - once an app gets to a certain complexity, knowing that a form was renamed, a field was added or a function was updated, is far from knowing what I was intending to address with a new release. Usually, new releases bring in new features or address issues, which often need many changes in various different areas (rework forms, new relations, update a function or two, update existing policies, etc.). So over the years, we started to write down why we were making changes and used these notes for testing and, later, for the change log.
It would be possible to add systems in r3 to load older or newer JSON versions, to then parse and display these against the current schema (the current app state). But it would be a lot of effort for something I personally needed to do maybe once in 4 years. It would also be very complex, as apps not only need to consider their state - but the state of all dependencies (eg. other apps they build on) to compare and validate changes. I have a colleague who is currently on vacation, who is doing a lot of app work lately - I want to talk to him as well to get his perspective.
I tend to believe it would be more useful to include a change log in the Builder, so that authors can note and explain their changes to others (and themselves, for when they work on the app later).
Merging changes from different versions / authors is not really an option for us as you already assumed. The added complexity and edge cases would make developing r3 incredibly difficult and would slow down development of new features accordingly.
