consolidate version numbers throughout all interfaces #592

williamboman · 2016-09-05T12:44:01Z

I find the current reporting of versions, both in the client and CLI, is a bit lackluster. For example, starting the server on latest master logs a message that (as of now) says The Lounge v2.0.0-pre.6 is now running ... when in fact master is 30 commits ahead of pre-6.

This PR consolidates version numbers reported in the client and the CLI. Effectively, this means there'll only be visible changes when starting lounge through the CLI;

williamboman · 2016-09-05T12:45:37Z

src/command-line/index.js

@@ -7,7 +7,7 @@ var fsextra = require("fs-extra");
 var path = require("path");
 var Helper = require("../helper");

-program.version(pkg.version, "-v, --version");
+program.version(Helper.getVersion(), "-v, --version");


Not sure how I feel about this one though. ¯_(ツ)_/¯

I remember getting the same feeling when implementing the UI version. This is what should be displayed:

If this is a git repository, git is available and git command is available, display git commit.

Otherwise, display npm version

As an amendment to (1.), if the commit hash has an exact match for an npm version (i.e. a tag), we may want to display npm version instead. Though it might be a bit confusing as, essentially, instance is running from source and not from a build... so I'd say, if git repo + git available, go for git commit.

However, that npm version + commit hash (like in your picture above) is a no-no for me. As a user, what does that mean, am I running the pre.6 version or a specific commit? Is that commit hash related to that version? If I notice a bug, does that mean pre.6 have to be incriminated?
I'm in favor of simplicity here: an npm version, or a commit hash, but not both.

What do you mean by npm version? All versions are (so far) given git tags as well (which is what git-describe uses to produce these refs).

As a user, what does that mean, am I running the pre.6 version or a specific commit? Is that commit hash related to that version?

I can agree on that. What about 2.0.0-pre.6-31-gbdd3fec (dirty). The entire point of this PR is to move from just providing commit SHAs to something with more face value. What about the version displayed on the client? Does this apply to the client as well?

What do you mean by npm version?

Sorry, I should have defined terminology I was using:

What I call "npm version" is that human-friendly "1.5.0", "2.0.0-pre.6" string, whether it comes from a git tag or from the package.json file (let's call that simply a "version" from now on)

What I call "commit hash" is... well, a (7-char) git commit hash :-)

The entire point of this PR is to move from just providing commit SHAs to something with more face value.

But that's the issue here. There is no face value at all on an instance that runs a given version + N commits on top of it. We cannot inform the user about a version if a single commit has been added to it. What if that commit reverts all or part of a version (think issues added in pre.6)? What if that commit adds bugs? Should the users blame/report about that version or that commit?
For those reasons, I'd much rather take no "version responsibility" as soon as a single commit has been added to an instance.

What about the version displayed on the client? Does this apply to the client as well?

You raise a good point and I believe versions should match in both the console and the UI.
If we want to push the 🚲 🏠 further, if not on a version, console could list the latest version + all commits added to that version, but we're going waaaaay too far! After all, we can't be doing the admin's job when it comes to using git 😅
So yeah, I definitely believe same on console + UI, and if admin wants more info, well, git log is there for that.

Remove pkg definition as it's no longer used in this file.

williamboman · 2016-09-05T12:48:52Z

src/helper.js

@@ -1,14 +1,19 @@
+'use strict';


(const and let)

AlMcKinlay · 2016-09-05T13:34:07Z

So, the errors aside (because of the ES6 stuff, which we need to figure out), I like this. As far as I can see, it'll still show the npm version if it's installed from there?

williamboman · 2016-09-05T13:51:17Z

As far as I can see, it'll still show the npm version if it's installed from there?

Yes. This PR is pretty redundant in terms of the amount of users who'll notice a change (I'd say we're probably down to a few ‰ 😄).

williamboman · 2016-09-05T14:24:05Z

src/helper.js

+	if (_gitRef) {
+		return _gitRef;
+	}
+	const commands = ["git describe HEAD", "git rev-parse --short HEAD"];


Just git describe HEAD should be enough. It was introduced in git@1.1.0.

So, if the first command succeeds, the for loop assigns stuff then continues to the next one, but if it fails, it... continues to the next one? 😅
Not sure that was the intent here.

Indeed, you can go with just one command, no need to over-complexify the code for this. Chances that the command is not available are way lower than not having git at all, and it's fine to default to npm version otherwise.

It'll try all commands in the array, as soon as one succeeds it'll cache the result for subsequent invokations and then return the stdout. If the command fails it'll continue to the next one, and if all fails return null.

astorije · 2016-09-06T04:31:23Z

src/helper.js

+				.execSync(`${command} 2> /dev/null`)
+				.toString()
+				.trim();
+			return _gitRef = gitRef;


Please break this down into 2 statements:

_gitRef = gitRef; return gitRef;

astorije · 2016-09-06T04:56:20Z

Hey @williamboman, thanks and good job consolidating versions!
A bit of an overkill at the moment though, see my comments above :D Almost there though.

One more comment. Maybe a stretch, but we have to get started somewhere: how easy/hard would it be to write a couple tests for this?

williamboman · 2016-09-06T09:05:17Z

Hey @williamboman, thanks and good job consolidating versions!
A bit of an overkill at the moment though, see my comments above :D Almost there though.

So firstly I think we need to agree on how to present the version number if the instance is running from source on a non-tagged commit. My preference is to use git describe to produce git refs that map a commit SHA to the closest release in history, e.g. v2.0.0-pre.6-2-gabcdef. I understand this could cause a lot of confusion though.

The other option would be to simply present the commit SHA (which is how it currently works). Then this PR would have to shift focus entirely to just consolidate version numbers throughout all interfaces.

One more comment. Maybe a stretch, but we have to get started somewhere: how easy/hard would it be to write a couple tests for this?

Tests for printing version numbers in the CLI, or?

astorije · 2016-09-07T06:04:21Z

My preference is to use git describe to produce git refs that map a commit SHA to the closest release in history, e.g. v2.0.0-pre.6-2-gabcdef. I understand this could cause a lot of confusion though.

My preference goes the other way around for said confusion, and other reasons described in a comment above (mostly because of the info being displayed doesn't reflect reality too well: this is not the running version anymore!).
Thoughts from others? :)

Then this PR would have to shift focus entirely to just consolidate version numbers throughout all interfaces.

I actually think that such consolidation would be pretty great already! Actually, maybe worth doing a first pass with that consolidation, then in a further PR play with the other options? There are actually many ways git can report this and we might want to look into it, while the other goal (UI+console consistency) is a no-brainer.

Tests for printing version numbers in the CLI, or?

I know, this is rather far-fetched and probably useless, but I'd love it if we could write tests for our app... So probably ignore my comment, but if you have a good and simple idea, I'll take it :-)

AlMcKinlay · 2016-09-07T07:17:58Z

Thoughts from others? :)

I like the idea of showing a version and a git commit, as it actually gives you an idea where you are on git, rather than having to open the commit and guess from the previous commits.

However, I don't use the version in the app enough to care. I understand the issues you have with it, @astorije and I won't argue it much.

williamboman · 2016-09-07T09:37:13Z

I'm just annoyed by the version number being reported in the CLI when running from source, hence this PR. I don't feel very strongly about the semantics so I've shifted the focus of this PR to solely consolidate version numbers reported by the app.

So effectively all this PR does now is change the output in the CLI when starting lounge;

williamboman · 2016-09-07T09:39:00Z

src/command-line/index.js

+	// Hack to defer execution of Helper.getGitCommit()
+	toString() {
+		return Helper.getGitCommit() ? Helper.getGitCommit() : pkg.version;
+	}


Thoughts? Feels a bit unnecessary to invoke Helper.getGitCommit() for every command.

Are you trying to check if Helper.getGitCommit exists? Because you are invoking it either way.

No, I'm deferring execution of toString until commander wants to use it. Might break other stuff since we're not passing a string though.

The overhead of spawning a child process to get the git SHA is pretty much non-existent though, but it feels a bit unnecessary to do it for every single command (especially since it'll fail since most lounge installations are done through npm, I assume).

xPaw · 2016-09-17T10:25:14Z

src/server.js

+	} else {
+		log.info(`The Lounge v${pkg.version} is now running`);
+	}
+	log.info(`Available on: ${protocol}://${host}:${config.port}/, in ${config.public ? "public" : "private"} mode`);


Remove the , after the url.

xPaw · 2016-09-24T19:16:14Z

Could you also add the commit in https://github.com/thelounge/lounge/blob/2bb782fe81089bc634ae4946c68806a6d89b6e99/src/client.js#L255

xPaw · 2016-09-30T19:18:44Z

src/server.js

+	if (Helper.getGitCommit()) {
+		log.info(`The Lounge is running from ${Helper.getVersion()}`);
+	} else {
+		log.info(`The Lounge ${Helper.getVersion()} is now running`);


Not a particular fan of using the ES6 bollocks. The log allows for concat by doing:
log.info("The Lounge", Helper.getVersion(), "is now running");

xPaw · 2016-09-30T19:19:10Z

src/helper.js

@@ -1,3 +1,6 @@
+"use strict";
+
+const pkg = require('../package.json');


Double quotes.

xPaw · 2016-09-30T19:20:48Z

src/server.js

-	log.info("The Lounge v" + pkg.version + " is now running on", protocol + "://" + (config.host || "*") + ":" + config.port + "/", (config.public ? "in public mode" : "in private mode"));
+	let protocol = config.https.enable ? "https" : "http";
+	let host = config.host || "*";
+	if (Helper.getGitCommit()) {


I'm not even sure this different message is needed, could always just be printing the else statement.

xPaw · 2016-09-30T19:21:40Z

src/server.js

@@ -121,7 +116,7 @@ function index(req, res, next) {
 			pkg,
 			Helper.config
 		);
-		data.gitCommit = gitCommit;
+		data.gitCommit = Helper.getGitCommit();


Can the frontend just use Helper.getVersion() too? Then the getGitCommit function is only internal and getVersion would be the single authority.

EDIT: It's required for a github link, nevermind.

astorije · 2016-10-10T18:12:21Z

@williamboman, could you rebase this PR with master please?

astorije · 2016-10-16T20:21:59Z

src/helper.js

+		return null;
+	}
+}
+


Not too happy this was merged with removed comments as mentioned below some time ago, but oh well.

consolidate version numbers throughout all interfaces

williamboman reviewed Sep 5, 2016
View reviewed changes

williamboman force-pushed the fix/git-describe branch from bdd3fec to ed6f062 Compare September 5, 2016 12:47

williamboman reviewed Sep 5, 2016
View reviewed changes

src/helper.js

@@ -1,14 +1,19 @@

'use strict';

Copy link

Member Author

williamboman Sep 5, 2016 •

edited

Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(const and let)

williamboman force-pushed the fix/git-describe branch from ed6f062 to 5ab09db Compare September 5, 2016 12:50

AlMcKinlay added the Type: Feature Tickets that describe a desired feature or PRs that add them to the project. label Sep 5, 2016

williamboman mentioned this pull request Sep 5, 2016

lint: default to ecmaVersion: 6, keep ecmaVersion: 5 for client/ #593

Merged

williamboman reviewed Sep 5, 2016
View reviewed changes

williamboman force-pushed the fix/git-describe branch 2 times, most recently from 44e190e to 1871457 Compare September 5, 2016 17:00

astorije reviewed Sep 6, 2016
View reviewed changes

williamboman force-pushed the fix/git-describe branch from 1871457 to 4e09276 Compare September 6, 2016 12:13

astorije self-assigned this Sep 7, 2016

williamboman force-pushed the fix/git-describe branch from 4e09276 to f5e155e Compare September 7, 2016 09:36

williamboman changed the title ~~use git-describe(1) to extract current git ref~~ consolidate version numbers throughout all interfaces Sep 7, 2016

williamboman reviewed Sep 7, 2016
View reviewed changes

williamboman force-pushed the fix/git-describe branch 3 times, most recently from 62a9bc5 to 986ab64 Compare September 7, 2016 14:06

xPaw reviewed Sep 17, 2016

View reviewed changes

williamboman force-pushed the fix/git-describe branch 2 times, most recently from e6c3c1a to d90465a Compare September 25, 2016 10:38

xPaw requested changes Sep 30, 2016

View reviewed changes

xPaw added this to the Next Release milestone Sep 30, 2016

xPaw self-assigned this Sep 30, 2016

williamboman force-pushed the fix/git-describe branch 3 times, most recently from 2283cfe to 442c284 Compare October 1, 2016 11:46

xPaw approved these changes Oct 1, 2016

View reviewed changes

xPaw modified the milestones: 2.1.0, Next Release Oct 2, 2016

consolidate version numbers throughout all interfaces

9921834

williamboman force-pushed the fix/git-describe branch from 442c284 to 9921834 Compare October 10, 2016 19:57

xPaw merged commit db1dc36 into thelounge:master Oct 15, 2016

williamboman deleted the fix/git-describe branch October 15, 2016 11:37

astorije reviewed Oct 16, 2016

View reviewed changes

src/helper.js

return null;

}

}

Copy link

Member

astorije Oct 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not too happy this was merged with removed comments as mentioned below some time ago, but oh well.

matburnham pushed a commit to matburnham/lounge that referenced this pull request Sep 6, 2017

Merge pull request thelounge#592 from williamboman/fix/git-describe

d7e4666

consolidate version numbers throughout all interfaces

xPaw unassigned astorije and xPaw Mar 12, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

consolidate version numbers throughout all interfaces #592

consolidate version numbers throughout all interfaces #592

williamboman commented Sep 5, 2016 •

edited

Loading

williamboman Sep 5, 2016

astorije Sep 6, 2016

williamboman Sep 6, 2016

astorije Sep 7, 2016

xPaw Sep 30, 2016

williamboman Sep 5, 2016 •

edited

Loading

AlMcKinlay commented Sep 5, 2016

williamboman commented Sep 5, 2016 •

edited

Loading

williamboman Sep 5, 2016 •

edited

Loading

astorije Sep 6, 2016

williamboman Sep 6, 2016

astorije Sep 6, 2016

astorije commented Sep 6, 2016

williamboman commented Sep 6, 2016 •

edited

Loading

astorije commented Sep 7, 2016

AlMcKinlay commented Sep 7, 2016

williamboman commented Sep 7, 2016 •

edited

Loading

williamboman Sep 7, 2016

xPaw Sep 17, 2016

williamboman Sep 17, 2016 •

edited

Loading

xPaw Sep 17, 2016

xPaw commented Sep 24, 2016

xPaw Sep 30, 2016 •

edited

Loading

xPaw Sep 30, 2016

xPaw Sep 30, 2016

xPaw Sep 30, 2016 •

edited

Loading

astorije commented Oct 10, 2016

astorije Oct 16, 2016

		@@ -1,3 +1,6 @@
		"use strict";

		const pkg = require('../package.json');

consolidate version numbers throughout all interfaces #592

consolidate version numbers throughout all interfaces #592

Conversation

williamboman commented Sep 5, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

williamboman Sep 5, 2016 • edited Loading

Choose a reason for hiding this comment

AlMcKinlay commented Sep 5, 2016

williamboman commented Sep 5, 2016 • edited Loading

williamboman Sep 5, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astorije commented Sep 6, 2016

williamboman commented Sep 6, 2016 • edited Loading

astorije commented Sep 7, 2016

AlMcKinlay commented Sep 7, 2016

williamboman commented Sep 7, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

williamboman Sep 17, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xPaw commented Sep 24, 2016

xPaw Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xPaw Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

astorije commented Oct 10, 2016

Choose a reason for hiding this comment

williamboman commented Sep 5, 2016 •

edited

Loading

williamboman Sep 5, 2016 •

edited

Loading

williamboman commented Sep 5, 2016 •

edited

Loading

williamboman Sep 5, 2016 •

edited

Loading

williamboman commented Sep 6, 2016 •

edited

Loading

williamboman commented Sep 7, 2016 •

edited

Loading

williamboman Sep 17, 2016 •

edited

Loading

xPaw Sep 30, 2016 •

edited

Loading

xPaw Sep 30, 2016 •

edited

Loading