You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need App Stores (Apple, Google) strategy for version numbers, release status, alpha beta rc, etc. #35
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.
Activity
wolfmcnally commentedon Feb 12, 2021
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.
wolfmcnally commentedon Feb 12, 2021
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.
ChristopherA commentedon May 25, 2021
@Fonta1n3 @wolfmcnally
Are we now being consistent here for Guardian, UR Vault and Gordian Cosigner?
ChristopherA commentedon May 10, 2022
@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.
shannona commentedon May 25, 2022
I've added a link to our Community README, which has this sort of info.
https://github.com/BlockchainCommons/Community/blob/master/README.md