-
Also patches themselves would need maintaining if an app changed as they may then not apply cleanly. Not to mention how painful they would be to debug or change.
There's more to think about, but the simplest solution is to explicitly include the word "Patch" in the JSON of the application if it's a fork with minimal edits.
There will be an agreement: if your new application is an almost complete clone with minimal edits, then you must definitely specify the word "Patch" in the JSON. Further, such forked new applications will be placed in the "Patches" tab, where there can be any number of identical applications with minimal edits. How about this?
Ideally, there will be automation: a new app is being checked for a code match, if the code base matches by 80% (suppose), then the new app is automatically assigned the word "Patch" in its JSON, also can add a small ID in the form of a hash to the name. And all this is automatic.
Further, the author of the main origin app could use such patches for their origin app or ignore thats "patches" :)
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
Serj
@Gordon
Yes, exactly, it's usually quite easy. I guess maybe it would be possible to use the Github API to dig out who the authors were in an easy way? Or maybe there's a page I could just link to as I know GitHub lists icons for the top authors at the top of the directory list usually.
In theory I like this - I've been trying to tweak some of the apps in the app store (eg to allow fast loading, or swipeable widgets) and it's amazingly frustrating to find a whole bunch of apps that are basically identical apart from 2 lines of code.
But I just wonder whether anyone would actually use this? Handling patches is quite advanced when many contributors haven't even used Git before. Also patches themselves would need maintaining if an app changed as they may then not apply cleanly. Not to mention how painful they would be to debug or change.