Because GitHub explicitly disables fast-forward merges, our releases diverge from dev.
git describe prints string composed of Git information about current branch (HEAD), suitable to use as a version. Example repository:
The repository has 2 commits. HEAD points to tip of the master branch, which is a commit on top of v1 tag (release).
git describe makes best effort to print most meaningful string representation of HEAD. In this case it encodes
latest parent tag (v1)
number of commits on top of latest tag (1)
short commit ID of top commit (g67c0d62)
In case there's a tag corresponding to HEAD commit, only the tag name is printed:
In the first snippet I run git describe on rchain dev branch. The resulting string says that
first reachable tag from dev is v0.4.1,
dev as of 2019-02-04 is 5435 commits on top of v0.4.1 and
top commit on dev is gfb4e0bfa0.
So this means that v0.4.1 was created either directly from dev or from a branch fast-forwarded to dev.
git describe strings would be ideal for our version numbers. To get latest version of dev branch in https://build.rchain-dev.tk/branches/dev/, you actually need to sort the files by date (What's newer? rnode-0.8.3.git26990a59.tgz or rnode-0.8.3.git35342d8b.tgz?). git describe version strings would make it possible to compare two pre-release versions.
Sure, we could create version numbers with counters manually, but, ignoring the additional effort, we don't really have any point to start count from, because our release tags point to commits that are not reachable on dev branch.
The version strings are perhaps minor issue, but in general, we're using Git branches in official repository wrong.
In Git, tags in no way correspond to branches. Both tags and branches are pointers to Git objects that form tree-like structure. The only difference is that branches move whereas tags don't.
Branches are meant to be used for work (and possibly deleted when a topic is done). Tags are meant to point to milestones, forever.
We're forking branches from dev that are never updated and then we create tags from them. There's absolutely no reason to do this and due to GitHub behavior, it unnecessarily complicates Git history and prolongs releases (useless merge commit builds). If hot fixes on releases are anticipated, a branch can just be forked from a tag (v0.8.4), then fixes be done on it and new tag created from it (v0.8.4.1). Trying to map concepts from management to a tool that can easily accomplish required goals with its own concepts leads to unwanted problems and wasted effort.
I propose we start using branches only for actual work. Let's continue using dev as master and stop merging to mater/testing/release-rnode-*, and tag releases directly from it. Because of the way Git works, there's absolutely no risk in doing so, we'll just simplify and improve our release process.