Closed ChristopherA closed 2 years ago
Here's what I know about Apple version numbers:
Here are the Android guidelines:
The thing I see in common is that Apple and Google both have a private version field that is not shown to users, and a public version field that is. In Google's case, it is required to be an increasing integer. In Apple's case, the same requirement is true for macOS, but for iOS it can be a dotted version number as long as it only increases. The least common denominator among the three is as I have recommended: Use the public-facing version string for the actual name of the upcoming release (starting at "1.0") and identify every release including internal ones using an increasing integer in the non-user-facing field. The public-facing field should not have exactly the same semantics as "semantic versioning," as this is more appropriate for developer-facing libraries; rather, it should be so users can identify bug-fix releases, minor improvement releases, and major improvement releases.
One of the nice things about using a monotonically-increasing integer for release number is that it is amenable to automated release processes. And even though it is not shown to the public, it can be revealed to testers. In the case of Apple's Test Flight, it automatically is revealed to testers.
@Fonta1n3 @wolfmcnally
Are we now being consistent here for Guardian, UR Vault and Gordian Cosigner?
@shannona is this now done to our satisfaction? Is it linked in appropriate places? If yes, link them here and let's close this issue.
I've added a link to our Community README, which has this sort of info. https://github.com/BlockchainCommons/Community/blob/master/README.md
Need a proposal from @wolfmcnally