Simplify Git releases

Description

Short story

Because GitHub explicitly disables fast-forward merges, our releases diverge from dev.

1 2 3 4 % git symbolic-ref --short HEAD # in rchain repo, on dev dev % git describe v0.4.1-5435-gfb4e0bfa0

Theory

git describe prints string composed of Git information about current branch (HEAD), suitable to use as a version. Example repository:

1 2 3 % git log --oneline 67c0d62 (HEAD -> master) second 9c7169a (tag: v1) first

The repository has 2 commits. HEAD points to tip of the master branch, which is a commit on top of v1 tag (release).

1 2 % git describe --tags v1-1-g67c0d62

git describe makes best effort to print most meaningful string representation of HEAD. In this case it encodes

  1. latest parent tag (v1)

  2. number of commits on top of latest tag (1)

  3. short commit ID of top commit (g67c0d62)

In case there's a tag corresponding to HEAD commit, only the tag name is printed:

1 2 3 % git tag v2 % git describe --tags v2

In the first snippet I run git describe on rchain dev branch. The resulting string says that

  1. first reachable tag from dev is v0.4.1,

  2. dev as of 2019-02-04 is 5435 commits on top of v0.4.1 and

  3. 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.

Long story

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.

Status

Assignee

Kelly Foster

Reporter

Tomáš Virtus

Components

Story Points

None

Epic Link

None

Labels

None

Priority

Medium