split gomockhandler.json into configuration file and mocks status file

[sanposhiho]

from #59

Let's move source_checksum and checksum from gomockhandler.json to new 'mocks status file'.

with this

• we can make configuration file more readable
• we can allow user to edit configuration file directly

[riita10069]

Hi! @sanposhiho
Does this Proposal maintain downward compatibility with existing projects?

[sanposhiho]

Maybe yes.
I think we can achieve this without breaking existing projects. But it's possible we'll find out that we can't during developing this feature.

my plan:
In order not to break existing projects, when we use mock status(= source_checksum and checksum) in each command,

• basically, we check the new mocks status file and use mock status in it
• and we also check source_checksum and checksum on gomockhandler.json
• and if we find them on gomockhandler.json, we move them to the new mocks status file.
• and then, delete them from gomockhandler.json.

This means that the gomockhandler.json is allowed to have source_checksum and checksum and they will be automatically moved to the new mocks status file.
And when we release v2, we can delete source_checksum and checksum from gomockhandler.json.

wdyt?

[riita10069]

I think we must consider some situations about Coexistence.
if it fouund new mock status file, but gomockhandler.json has mock status too.
Can it recognize the gomockhandler.json's mock status?

and if new mock status file and gomockhandler.json has different value of checksum as to same source.
what should it behave?

A person who somehow upgraded its version will run a new command without realizing that the json file has been split.

[sanposhiho]

if new mock status file and gomockhandler.json has different value of checksum as to same source.
what should it behave?

The checksum on new mock status file should take precedence. And the one on gomockhandler.json will be deleted at that time.

Basically, we should consider backward compatibility when we increment minor versions, but don't always need to forward compatibility including what happens when a project has both people using the old version and people using the new version.

Users on the same project should use the same version of tools ideally.

[riita10069]

I understand.
So it always works to converge to a newer version of json. Including existing files.
Thanks for the reply.