explore semantic versioning

[incanus]

Via Will: http://semver.org/

Current system looks like this:

1. Tag 1.x following last tag used when doing a build. Example: 1.27 follows 1.26.
2. Choose cosmetic version number. Example: 1.3.
3. App gets submitted & shows up on OS as 1.3.
4. Help/about dialog lists 1.3.127, removing periods from tag used.

The main requirements that this meets are:

• Cosmetic version number is independent of build process.
• Allows for multiple builds of a cosmetic version number during testing & internal distribution.
• Able to identify conclusively exactly which commits exist in a given app build, whether internal or external.
• Don't have to hassle with build version identification -- it's automated.

One approach I could see is using semantic versioning (i.e. x.x and x.x.x only) plus a SHA-1 hash for internal builds to distinguish them. So, something like 1.3 (538dae) for internal builds and 1.3 for releases.

Thoughts?

[incanus]

Also related to this -- we still need (or it would at least be nice to have) a bundle version that shows up here, which is what our tag is doing presently:

[willwhite]

Justin, are you getting a 404 for that image ?

[incanus]

Fixed the 404. I'm not quite sure how GH does inline images. I thought it grabbed them for itself, but it looks like it just puts them on CDN but still references the original.

[willwhite]

Yeah let's give this approach a shot. I like the idea of using the git hash.