-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Add top-level version
package
#583
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #583 +/- ##
===========================================
+ Coverage 57.09% 57.11% +0.01%
===========================================
Files 122 122
Lines 14646 14652 +6
===========================================
+ Hits 8362 8368 +6
Misses 5567 5567
Partials 717 717
|
29e548e
to
70c8363
Compare
Closed probably because of Cmd-Enter closing it? Re-opened now. |
Didn't use the new-in-1.18 capability https://pkg.go.dev/runtime/debug#BuildInfo because we currently on 1.17. To have it work properly via Docker we copy the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good. I look forward to discussing my suggestions bellow 😁.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🌞
I have been reviewing the PR, and I had several pending comments, and I realized they are all along the same theme, so I figured I would just make a single comment now about the nature of this package, we can discuss/resolve the comment, and depending on that descision, I can submit my actual review, or you make the necessary changes. I'm trying to determine the scope of this top-level version package. The original intent was just as a place to hook in the compiler LDFLAGS at build time to hook into the build version info (date, time, git commit, tag, go version, etc). But this PR has moved almost anything related to versionining here. I personally like the simplicity of the build-only approach, additionally, any version information that is currently package-specific (ie: TLDR; I don't think version information beyond the build info should be in this package. This is entirely open for debate. |
I thought this had been discussed prior to the PR so I didn't want to argue the migration. But I do prefer having the package specific versions residing inside those packages. |
I agree with the guideline of colocating information. In this case, it seems to me that some in-package version information is to be used externally. Specifically, I can think of at least 3 consumers of the information.
Because there is additional logic relevant to versioning, such as serialization, comparison, and potentially assisting with a deprecation policy, I saw It is also possible for each package-specific version information to remain in its package, but to be gathered by a |
I'll update in light of today's discussion |
1d098fb
to
f3ed7f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks good. Only a few things I think should be improved and then it will be good to go :)
ac77ff3
to
ff8cd26
Compare
Thanks @fredcarle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes Orphée!
ff8cd26
to
aadc87c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the excellent work on this Orhpheee!
In addition to the comments / suggestion I left I was wondering specifically for the non-json command (i.e. defradb version
) that we are going from this:
To:
I know we planned to add global color support in future so that is fine, but maybe we can make the text output slightly more pretty =D?
Here is a suggestion (I don't think we need branch
):
DefraDB's Version Information:
* branch : master
* build commit : e4328e0
* release date : 2022-03-07T00:12:07Z
* version tag : 0.2.1
Other Version Information:
* dockey versions : 1
* golang : 1.17.8 linux/amd64
* http api : v0
* net protocol : /defra/0.0.1
@shahzadlone not sure how to reply directly to your latest suggestion about making the output prettier. What do you think of this suggestion? We can imagine later on adding on color when shell environment supports it.
|
Adding colour is pretty easy if you want to add it. |
I like this better than original, but why not indentation for the lines after the title and
|
Yes but it should be a different PR to enable a global color flag and color in multiple places. |
My preference and suggestion now is to use a one-liner for the human version:
Thoughts? |
Too long of a line I feel like. Probably nitpicking at this point but If someone's running defradb on a remote server and have a tiny terminal screen, version info is going to be on one long horizontal line that will be wrapped into multiple lines? Previous suggestions keep them readable even for a small terminal window (I don't see the appeal of it all being squished to 1 line). |
I expect most contemporary terminal displays to show be able to show ~70 characters without issue, therefore I don't see it as a problem. |
That would be an awfully small terminal lol. The one liner is fine to me. I've seen many other projects use it. But I don't mind multiline either. At this point it's really a matter of personal preferences. |
I suggest that an advanced user that cares about which DocKey versions and netprotocol are supported can obtain it with via the JSON output. |
characters alone isn't an accurate measurement, size and type of font can change that somewhat.
I like one liner as long as it's not too long (for example the way golang does it). Here is the output on my 17inch screen with one tmux split:
I would strongly suggest that the only difference between |
The output you show, found below, is displaying version information on a development branch. It has 99 characters in this case, but depends on the branch name.
The vast majority of users will use a stable release and will see something like the following which in this case has 71-2 characters, as it uses tag from the master branch.
|
The status quo is to provide the useful information for the vast majority of use cases as a one-liner. An option is to expose the parity of information between human & JSON, for the advanced users, under a |
By default maybe we print the longer version (for both As mentioned these are nitpicks (non-blocking). I leave the final style choice up to you =) |
The version information for human is used when debugging collaboratively or deployed nodes, or when creating issues. I suggest the short version should be the default, as the extra information is most likely derivable via the short version information. I'll add a |
cf689ca
to
f0cd8d4
Compare
Relevant issue(s)
Resolves #349
Description
Add a central top-level
version
package where version information, of DefraDB itself, its protocols, and API versions, etc can be determined and used in other packages. Both the idea and discussion are, of course, up for discussion.NOTES:
--version
flag which allows to provide version information on the root command, but aversion
command seems preferable.Tasks
How has this been tested?
Manual testing.
Specify the platform(s) on which this was tested: