Set current version defined by version number and build number in main build file

[wuan]

This should allow the downstream F-Droid build to pick up the current version numbers.

Code Review Checklist

• Description accurately reflects what changes are being made.
• Description explains why the changes are being made (or references an issue containing one).
• The PR appropriately sized.
• New code has enough tests.
• New code has enough documentation to answer "how do I use it?" and "what does it do?".
• Existing documentation is up-to-date, if impacted.

[donpui]

Change to 1.0.1+30

[donpui]

There are some IOS related commits. Should they be here?

[wuan]

No, they are gone now.

[meejah]

Are these versions public (like, do users see them)? It would be odd to "upgrade" from 16.0.0 to 1.0.1+30 (whatever that means). Elsewhere we talk about CalVer; does this have a "versioning scheme"?

[donpui]

This is more cleanup activity as pubspec has demo entry. Current public version is 1.0.1 (previous 1.0.0), if we are not using parameters during build, then value from pubspec will be taked. 1.0.1 is version name, 30 is version code (which in android case should be incremental number): https://developer.android.com/studio/publish/versioning

[wuan]

@meejah, so far we did not reflect the version number we were actually using somewhere in the configuration/code. This is what we should do and what is a requirement when deploying to F-Droid. If you look at the releases on GitHub or in our Play Store entry you will see the versions 1.0.0 and the recent update to 1.0.1.