Release v0.5.4

[yarikoptic]

We need to release so ppl (including myself) could take advantage of the fixes

TODOs:

• Expand changelog entries to human-understandable entries

@mgxd Could you please elaborate on those changes we had merged? ;)

[codecov-io]

Codecov Report

Merging #315 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #315   +/-   ##
=======================================
  Coverage   74.31%   74.31%           
=======================================
  Files          35       35           
  Lines        2667     2667           
=======================================
  Hits         1982     1982           
  Misses        685      685

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff845bb...36e08d8. Read the comment docs.

[satra]

@yarikoptic - to reduce human burden, i would suggest that we make sure this is done on the issue link, rather than in the changelog. i'm completely fine with assuming internet connectivity.

[yarikoptic]

I would agree to disagree. For me it is not about being able to discover more detail about an issue, but having a concise summary of changes which you can glance over to see if the issue of possible interest to you was fixed and when. I have benefited greatly on many occasions from good changelogs.
Reducing human burden though is a nice goal to have in the long run. On one occasion (with duecredit iirc) I was trying to get changelog autogenerated from PR messages etc, but it didn't "streamline". So so far I just typically benefit from good merge/commit messages and "git log" to compile a list of items for the changelog. @kyleam is even more efficient in his practice. I feel that if, while merging PR, we provide a one line summary (while also leaving PR's number in () for autolinking with the script I added here) it would be close to ideal. I will try from now on to resort to such a practice (unless on the phone ;))

[yarikoptic]

I think that we better retract this, at least partially. I am ok with having :unstable to depict the master version, although master could be cleaner and more to the point. We need release tags (ATM I see only debian (which is not needed really) and unstable), and then latest to point to the latest release. Is that possible to easily automate @mgxd ?

[mgxd]

@yarikoptic @satra :unstable was meant to grab the users attention and be aware this is not an official release - the name may sound scarier than it actually is 😅

The main factor for this change was we were missing versioned releases, so after this first one things should go over much smoother. If renaming :unstable to either :master or :dev helps, that is fine with me.

I go back and forth on whether we should have a :latest pointing to the most recent versioned release: on one hand, it would be convenient for new users to pull. But when a new version is released down the line - these people would need to explicitly run docker pull or else be stuck on a previous release (which would make the latest tag misleading)

[yarikoptic]

@yarikoptic @satra :unstable was meant to grab the users attention and be aware this is not an official release - the name may sound scarier than it actually is

The main factor for this change was we were missing versioned releases, so after this first one things should go over much smoother. If renaming :unstable to either :master or :dev helps, that is fine with me.

I would vote for :master since it has 1:1 correspondence to what it is -- master branch. unstable might come from whatever, could be "unstable release", etc. Thus lacks clear semantic.
I am ok, and welcome to have it! ;)

I go back and forth on whether we should have a :latest pointing to the most recent versioned release: on one hand, it would be convenient for new users to pull. But when a new version is released down the line - these people would need to explicitly run docker pull or else be stuck on a previous release (which would make the latest tag misleading)

I hear you. I think in an ideal world :latest (if specified explicitly on docker run) should auto-cause docker pull to verify that it is the latest release. But that is not how it goes ATM. My peace of mind semantic for it is: "latest" is "the latest release available" -- locally (for run) or remotely (for pull). It is the default tag used by docker so that if there is no :latest and no tag - nothing is ran (locally) or pulled (remotely). That causes my personal headaches, and thus I am whining here.
If we force users to use :master and :version, and thus removing even ability to just get the latest release, we are causing the effect which you are actually trying to avoid -- people will less likely to run a new version, since it requires additional effort to first figure out what is that version!

[satra]

is this ever going to happen :)