Adopt a versioning scheme, & deploy from tags

[dmolesUC]

Merritt Dashboard versioning proposal

1. Use Calendar Versioning.
2. Use what calver.org would call a YYYY.MAJOR.MINOR scheme — four-digit year, major release, minor release.
3. Tag versions when we deploy them to development for testing.
4. Deploy from tags, not dev/stage/prod branches. Tags in git are attached to a specific commit hash. A branch merge (other than a clean "fast-forward" merge) changes the commit hash. If we don't deploy the same commit hash on dev and production, they can't share the same tag, and we can't use the Capistrano REVISION file to match them up (at least, not detective work).
5. Retroactively tag at least the last few of the following releases:

Deployed	Env	Commit	Tag	Content
2018-05-07	production	bd476262	2018.2	support MD5 from an ATOM feed submission
2018-05-02	development	930480fd	2018.2.1	add object/version/file too large messages
2018-05-02	development	096a4c53	2018.2.2	update deployment config to reflect move from hg to git
2018-05-03	stage	d75a6127	(none)	( merges above to stage branch)
2018-06-25	development	2749eb0d	2018.2.3	introduce unit tests, Travis CI
2018-06-25	development	c84cbed1	2018.2.4	update Capistrano and SSH gems
2018-06-25	development	ce9f5368	2018.3	update Ruby to 2.4, update related gems

We have commit hashes for some earlier releases on production, but since they refer to the old Mercurial repository it's hard to know what was in them. Anyway, only one was in 2018, so we can think of that one as "2018.1" (although I probably wouldn't go to the trouble of trying to find the corresponding git revision and tag it).

Note that revision bd476262 (proposed version 2018.2) here is the latest code actually deployed to production.

[jimvanderveen]

This looks pretty good to me, David.

[briri]

seems like a good approach to me as well. I like the idea of including the year as it could help identify an older version if its related to a specific feature.

[dmolesUC]

I've created the tags above:

$ git tag --list -n1
2018.2          support MD5 from an ATOM feed submission
2018.2.1        add object/version/file too large messages
2018.2.2        update deployment config to reflect move from hg to git
2018.2.3        introduce unit tests, Travis CI
2018.2.4        update Capistrano and SSH gems
2018.3          update Ruby to 2.4, update related gems

Weirdly, there doesn't seem to be any way in the git tag --list command to see the commit hash or the commit comment, but you can see them with git log:

$ git log --oneline --decorate --tags --no-walk
ce9f5368 (tag: 2018.3, origin/master, master) Merge pull request #3 from CDLUC3/ruby-upgrade
c84cbed1 (tag: 2018.2.4) Local Capistrano version at 3.4.1
2749eb0d (tag: 2018.2.3) Merge pull request #2 from CDLUC3/spec-rewrite
096a4c53 (tag: 2018.2.2) Switch deployment to git repo (from Hhg Rhodecode)
930480fd (tag: 2018.2.1) Generate just one message if any files too large
bd476262 (tag: 2018.2) merge with stage

We had two other tags, creating_stage_branch_off_of_prod_branch (rev. d5a55a6c) and datashare_prod (rev. 077cdaed), both from 2012. I went ahead and deleted those, so the tag list now only shows “release” tags.

[dmolesUC]

Fixed in edd7de7 / 2018.3.1