Bump version and publish latest UI improvements and bux fixes

[pcowgill]

Once #333 and #331 are merged

[pcowgill]

@marcelomorgado I think the last commit from this PR #324 is the best one test to test an upgrade from to make sure there are no problems with the changes in persistent storage

[pcowgill]

So this commit 5cc4c82

[marcelomorgado]

Are we'll use that commit or the develop branch after merging fixes and reset accounts?

[pcowgill]

@marcelomorgado Oh, good question. I guess that branch may not have been up to date with develop before merging it. Did the fixes you have in mind hit develop before or after merging that PR? Either way, we'll want the last commit from right before we actually published

[pcowgill]

It does look like develop was merged into that branch though, so I think it should have most of the fixes you're referring to if they were in develop before that PR #324

[marcelomorgado]

I think that I wasn't clear on my question.
I've meant if we will publish a new version from this commit 5cc4c82
Or using the updated code with last changes (account reset) from branch #343
I've made that question because I've thought that commit has the storeIsFirstUse(false) command and it could be a problem with our intent to reset all accounts. But I've just realized that commit hasn't this command.

[pcowgill]

Oh no, we definitely wouldn't want to publish from 5cc4c82. That's the commit that I was saying would represent what's already been published for testing the upgrade path. So we'd use that as the BEFORE in a BEFORE and AFTER data migration test on our devices before publishing.

We would want to publish the code with the latest changes for sure.

Yeah, it would have been bad if we published an intermediate commit. And yeah, I think that commit 5cc4c82 was from before we made those changes.

[marcelomorgado]

Ohh I see.

[pcowgill]

@marcelomorgado So does that commit work as the BEFORE commit then? If so, I'll begin testing and use the open PR as the AFTER commit

[marcelomorgado]

Okay