Once we release the 1.0, none of the code in gi.app or gi.actions that the contracts interact with is allowed to be changed in any way ever again. It cannot be deleted. It cannot be modified. Not even if there's a bug. From that point on the only thing that's allowed is adding new code. And the same applies for all of the new code that makes it in — once it's released publicly, if it is called in any way from the contracts (either directly, or via event listeners), it is not allowed to be modified ever again. This is to guarantee consistent behavior.
If we version controlled the app UI code so that the version of functions that was shipped with the version of the contracts were always kept version controlled together, this would not be necessary. But we don't do that right now.
EDIT: for now if you need to make a modification to such a piece of code, you can copy it and modify the selector to add a version number and use the new version in the new contract code. Examples:
Events: Say you want to modify switchCurrentChatRoomHandler in app/chatroom.js. You would need to copy this code:
Actions: Say a contract calls 'gi.actions/identity/kv/setChatRoomReadUntil' and there's a bug in it. You would need to copy the code for that selector and rename it to 'gi.actions/identity/kv/setChatRoomReadUntil/v2' before making your changes to it, and then calling the new version from the new contracts
But here's the important thing: any other code that is touched by any of these actions must ALSO be preserved. So that means if one of these actions or event listeners calls some other piece of code, for example, setCurrentChatRoomId in model/chatroom/vuexModule.js , that means you cannot modify setCurrentChatRoomId either! It too must remain frozen in time. All code that is a dependency of code that is called by contracts must remain frozen.
Solution
Design a way to version control all of the relevant frontend UI code as well.
Problem
Copying from Slack:
Once we release the 1.0, none of the code in
gi.apporgi.actionsthat the contracts interact with is allowed to be changed in any way ever again. It cannot be deleted. It cannot be modified. Not even if there's a bug. From that point on the only thing that's allowed is adding new code. And the same applies for all of the new code that makes it in — once it's released publicly, if it is called in any way from the contracts (either directly, or via event listeners), it is not allowed to be modified ever again. This is to guarantee consistent behavior.If we version controlled the app UI code so that the version of functions that was shipped with the version of the contracts were always kept version controlled together, this would not be necessary. But we don't do that right now.
EDIT: for now if you need to make a modification to such a piece of code, you can copy it and modify the selector to add a version number and use the new version in the new contract code. Examples:
switchCurrentChatRoomHandlerinapp/chatroom.js. You would need to copy this code:And create new events and new event listeners:
'gi.actions/identity/kv/setChatRoomReadUntil'and there's a bug in it. You would need to copy the code for that selector and rename it to'gi.actions/identity/kv/setChatRoomReadUntil/v2'before making your changes to it, and then calling the new version from the new contractsBut here's the important thing: any other code that is touched by any of these actions must ALSO be preserved. So that means if one of these actions or event listeners calls some other piece of code, for example,
setCurrentChatRoomIdinmodel/chatroom/vuexModule.js, that means you cannot modifysetCurrentChatRoomIdeither! It too must remain frozen in time. All code that is a dependency of code that is called by contracts must remain frozen.Solution
Design a way to version control all of the relevant frontend UI code as well.